Build a WebMCP app: 2026 challenge, showcase patterns, and readiness checklist

WebMCP lets websites expose browser-native tools that AI agents can discover and call. A WebMCP app registers typed JavaScript tools or HTML-form tools under document.modelContext, then an agent in the same browser session can call them instead of reading screenshots and clicking. The 2026 WebMCP Challenge closes September 3, 2026 at 1:00 pm Pacific Time, and a judging-ready entry needs a working hosted app, a public open-source repository, and a short public demo video. This guide covers what a WebMCP app is, the patterns the showcase apps use, how to design and test tools, and a submission checklist you can work through before the deadline.

WebMCP is still a proposed standard, so treat this as a design-and-test exercise rather than a production dependency. You can prototype today with the Chrome local flag and Cloudflare Browser Run lab sessions.

Fast decision:

• Build a WebMCP app if you want a concrete share of the agent-readable web and a deadline that forces scope.
• Expose narrow, typed tools per page rather than one generic "run anything" tool.
• Keep server-side checks for anything that costs money or changes the world.
• Ship a demo video under three minutes even if the judges may not open your app.

What a WebMCP app is

WebMCP is a proposed web standard for exposing structured tools to AI agents. Two surfaces do the work:

The specification frames WebMCP tools as JavaScript functions with natural language descriptions and structured schemas, designed for collaborative workflows where a user and an agent work in the same web interface. It is an alternative to an agent inferring a workflow from screenshots, accessibility trees, and selectors.

Constraints you hit on day one

WebMCP is gated, so plan for these before you pick a framework:

• Origin isolation. WebMCP is only available in origin-isolated documents. The APIs are disabled if document.domain is enabled, for example through the Origin-Agent-Cluster: ?0 HTTP header.
• Permissions policy. The tools permissions policy defaults to self, which allows tool registration in top-level and same-origin contexts and disables it for cross-origin iframes. To expose tools to a cross-origin iframe, add allow="tools" to the iframe.
• Browser coverage is experimental. Chrome starts a public origin trial from Chrome 149. For local work, enable chrome://flags/#enable-webmcp-testing. Cloudflare Browser Run offers experimental lab sessions on a Chrome-beta pool; its standard production pool stays on stable Chrome and does not expose WebMCP.
• navigator.modelContextTesting is a separate surface to inspect and invoke tools during development. You can call listTools() to see what is registered and executeTool() to test a single tool call.

A note on API naming: the current W3C draft and repository use document.modelContext for the tool registry, while Cloudflare's Browser Run documentation still references navigator.modelContext. Test against the browser you actually target and treat the naming as version variance in an evolving spec. Do not hard-code a name across both surfaces without checking the live build.

The 2026 WebMCP challenge

The WebMCP Challenge is a public, online hackathon run on Devpost. The official submission period runs from August 25, 2026 at 11:00 am Pacific Time through September 3, 2026 at 1:00 pm Pacific Time.

A complete entry needs four pieces, per the official rules:

Judging and the rules that trip people up

• Judges are not required to test your project. They may judge from the description, images, and video alone. Make the live URL and the README as clear as possible, and keep the project free and accessible until judging ends.
• No cap on team size. Prize items such as a ChatGPT Pro account or swag may cover a specific number of team members; that is a limit on the prize, not the team.
• Reusing an existing project is allowed with a strict rule. A project that existed before the submission period must be meaningfully extended using WebMCP after the submission period begins, and you must document what is prior work versus new WebMCP work. The FAQ makes the cutoff explicit: WebMCP work added before August 25 does not count.
• Do not touch anything after the deadline. The FAQ instructs entrants not to edit the Devpost submission, the repository, or the live site after the submission period closes until winners are announced. If you want to keep building, fork into a separate copy and leave the submitted version untouched.

Prizes

The challenge page advertises ten winning submissions. The enumerated bundle includes cash, coding access, and account benefits, plus supporter prizes. Quote the challenge page for current prize details rather than assuming a per-winner cash total, because the page describes some awards as credits or merchandise rather than a uniform cash payout.

Patterns from the showcase apps

OpenAI's showcase lists WebMCP apps that share a clear design philosophy: the user keeps using the app normally, and the agent acts through named, scoped tools on the same state. These are patterns you can reuse, not production conformance claims.

The through-line is a collaborative, same-state pattern. The agent is a capable collaborator with explicit verbs, not a proxy that hides the interface. Two design ideas recur:

• The agent acts under its own identity. In Margin Editor, Codex can add notes and comments without impersonating the person, so edits are attributed and a human can review them.
• The human stays in charge of the same object. In Sunday Table, the person keeps making their own changes while the agent helps plan. In Webroom and Codex Modeling Studio, the human watches each change and steers the next one.

When you design your app, pick one of these collaboration models and make it explicit in the description and the demo: the agent edits alongside the human, or the human approves before the agent acts.

Design WebMCP tools

The core design unit is a tool: a name, a natural-language description, and a JSON schema for its inputs. A narrow, well-described tool is easier for an agent to choose correctly than a broad one.

The simplest imperative registration exposes a registry surface on document.modelContext:

const mc = document.modelContext;

mc.registerTool(
  {
    name: "search_location",
    description: "Search a travel location and return matching places.",
    schema: {
      type: "object",
      properties: {
        query: { type: "string", description: "Place name to search" }
      },
      required: ["query"]
    }
  },
  {
    handler: async ({ query }) => searchLocations(query)
  }
);

Three decisions matter more than the API details:

• Keep tools scoped to the page state. Tool availability should change as the user moves through the app, not stay globally registered. The Cloudflare Browser Run guidance is to list tools on every page load, prefer WebMCP tools over clicking and typing, execute them, and re-list after each action because the available tools change with page state.
• Give every write a server-side check. Reading is low risk; changing a cart, creating a note, or ordering is where you need identity, object access, idempotency, CSRF defenses, audit logging, and human approval. Never rely only on the tool description to keep an action safe.
• Choose one collaboration model and say it out loud. Is the agent allowed to change shared state directly while you watch, or must a human approve first? Your description and demo should make that boundary visible.

For forms, the declarative API lets the browser synthesize tool definitions from HTML form elements and standard inputs, which requires less custom JavaScript when your workflow is form-shaped.

Test and measure readiness

Because WebMCP is experimental, test in the environment that matches your target rather than assuming a stable browser.

Local testing. Enable chrome://flags/#enable-webmcp-testing in Chrome 149 or later. Use navigator.modelContextTesting.listTools() to confirm which tools are registered on the current page, then navigator.modelContextTesting.executeTool() to invoke one with a JSON-encoded argument:

await navigator.modelContextTesting.listTools();
await navigator.modelContextTesting.executeTool("search_location", JSON.stringify({ query: "Paris" }));

Browser Run lab sessions. Cloudflare Browser Run exposes WebMCP in experimental lab sessions on a Chrome-beta pool. Lab sessions are experimental and are not for production workloads. Use them to verify that a downloaded site exposes tools and that a browser agent can call them end to end.

Readiness scoring. A third-party directory, webmcp.com, provides a live directory of websites exposing WebMCP tools, a read-only JSON API for discovery and schema inspection, and a scanner that loads a site like an agent and grades it on usability (60%), coverage (20%), and quality (20%). Treat this as one operator's methodology, not an official conformance test. It is useful as a quick external check that your site actually exposes discoverable tools.

Submission checklist

Work through this before the September 3 deadline. A sibling guide covers the Cloudflare-specific enablement and security of WebMCP; here the checklist focuses on a judging-ready entry.

• [ ] Pick one collaboration model (agent edits alongside, or human approves first) and state it in the write-up.
• [ ] Register page-scoped tools with clear descriptions and JSON schemas; confirm they list on the pages you demo.
• [ ] Keep writes behind server-side identity, object access, idempotency, audit, and human approval.
• [ ] Enable Chrome's local WebMCP flag and confirm your tools appear via listTools() and run via executeTool().
• [ ] Optionally verify in a Cloudflare Browser Run lab session that a real browser agent can call your tools end to end.
• [ ] Deploy a hosted URL and open it in ChatGPT's in-app browser or Chrome with WebMCP enabled; add credentials and steps if it is authenticated.
• [ ] Push a public repository with a visible open-source license and a README that explains the WebMCP fit and how to run it.
• [ ] Record a publicly visible YouTube demo under three minutes with audio that shows the app working and explains how you used WebMCP.
• [ ] Write the project description covering fit, improved UX, and what people and agents can do together.
• [ ] Freeze the submission, repo, and live site when the period closes; fork separately if you keep building.

For a working entry, plan the demo early: a clear three-minute video can carry your application even if judges do not open the live URL.

Verdict

A WebMCP app is a concrete way to participate in the agent-readable web now. The showcase applications show that the strongest projects keep a familiar user experience and give agents explicit, safe verbs rather than hiding the interface. The 2026 challenge gives you a hard deadline and a clear judging path, and the submission rules reward a crisp hosted app and a short demo video more than engineering complexity.

Build one if you want to ship something in the emerging browser-native tool ecosystem and you can keep writes behind server-side checks. Skip it if you need a stable production dependency today: WebMCP is still a proposed standard with experimental browser support, and it should not replace a working API or DOM fallback.

FAQ

Sources and links

Primary sources:

• WebMCP | AI on Chrome — Chrome for Developers
• WebMCP specification — W3C Community Group draft
• WebMCP repository — webmachinelearning
• WebMCP Challenge — Devpost
• WebMCP Challenge resources and FAQ — Devpost
• WebMCP Challenge official rules
• WebMCP · Cloudflare Browser Run

Showcase and directory:

• OpenAI Developers showcase — WebMCP apps
• Margin Editor showcase
• Crossword Desk showcase
• Verdant Market showcase
• Webroom showcase
• webmcp.com directory
• webmcp.com readiness methodology

Related AgentPedia guides:

• Cloudflare WebMCP: setup and security
• Cloudflare Kitesurf: agent-first browser
• Agent Plugins: portable skills and MCP