WebMCP Challenge backed by OpenAI and Chrome offers $35k for agent-ready sites

A ten-day sprint backed by a broad coalition

The WebMCP Challenge is live. According to a dev.to post written for participants, the hackathon runs from August 25 to September 3 on Devpost, offers $35,000 in prizes, and is backed by OpenAI, Chrome, Cloudflare, Shopify, Vercel, Render and Netlify — a lineup spanning model providers, browser makers, hosting platforms and commerce.

The task: build something with WebMCP, described in the post as a browser API that lets a page hand AI agents real tools to call instead of forcing them to click through a human-facing interface. Entrants have ten days.

Expose actions, not a chat box

The post's author, who says they have watched many WebMCP builds while maintaining an open-source WebMCP tool of their own, argues that demos succeed or fail on exactly two design decisions. The first is what a site registers as its tools.

The common reflex is to register a chat or "ask" tool that wraps the site's search box. That is backwards, the post argues: the agent is itself a conversational interface and has no need for a second one. What an agent genuinely cannot do is perform the site's actions — search a catalog, add to cart, check availability, book a slot, submit a form. Those are the tools a page should register.

The post walks through a worked example: a tool named search_catalog declares a JSON schema for its input, its execute function calls the site's search API, and the return value pairs human-readable text with structured content carrying the actual items found.

One implementation detail worth flagging: the post reports that the tool-registration getter moved from navigator.modelContext to document.modelContext on August 10, and recommends feature-detecting both and gating on support so ordinary browsers are unaffected.

The return value is a contract, not a UI

The second decision — the one the author identifies as the point where demos fall apart — is what a tool returns. A human reads the page; an agent reads the return value. A tool that performs its action and then returns a bare success flag, or navigates the page and returns nothing, leaves the agent without data for its next planned step, at which point it stalls or invents an answer.

The rule the post proposes: send back the real outcome as structured content — the items found, the new cart total, the booking confirmation number, the validation error — and treat every tool's return as an API contract the site now owes the agent.

Three failure modes are called out before recording a demo:

• Success flags: a search tool returning { ok: true } instead of the results
• Stale reads: returning cached state after an action has changed it
• Untyped errors: throwing a raw string instead of a structured error the agent can branch on

What the hackathon will not grade

A challenge judges a working demo, but the post identifies two concerns that will surface only once real agents hit a site.

The first is coverage drift. Each tool is written and updated manually; when the UI changes and a tool does not, the agent ends up invoking a tool whose behavior no longer matches the page. On a multi-page site, the author argues, keeping tools synchronized with the interface becomes most of the ongoing work.

The second is observability. Site owners currently cannot tell which agent called which tool, in what order, or whether responses contained usable data — none of that is visible today, and it is exactly what teams will want immediately after shipping.

For those wrapping an existing site rather than building from scratch, the post points to a shortcut: Latch, an MIT-licensed one-line script that auto-detects a site's search, cart and forms and exposes them as WebMCP tools. The author flags a disclosed bias here, stating they maintain an open-source WebMCP tool themselves.

Why it matters

The prize money is the small signal; the backer list is the large one. OpenAI, Chrome, Cloudflare, Shopify and three major hosting providers jointly encouraging builds against WebMCP points to real momentum behind a browser-level standard for agent-to-site interaction. If pages can expose their actions as callable tools with structured returns, agents gain a reliable channel into web functionality that does not depend on fragile UI scraping or simulated clicks — and being "agent-ready" becomes a deliberate implementation choice rather than luck. The dev.to post also previews what that work will actually look like: an API design problem rather than a UI problem, where the return contract and long-term tool maintenance matter more than the demo.