{"slug": "what-is-webmcp", "title": "What Is WebMCP?", "summary": "The W3C Web Machine Learning Community Group has published a Draft Community Group Report for WebMCP, an experimental browser API that lets websites expose structured tools to AI agents through document.modelContext. The imperative API registers JavaScript tools with JSON Schema input contracts, while Chrome's origin trial also implements a declarative API for HTML forms. WebMCP is separate from the server-oriented Model Context Protocol and is not yet a formal W3C standard.", "body_md": "# What Is WebMCP?\n\nWebMCP is an experimental browser API that lets websites expose structured tools to AI agents through document.modelContext. Learn how it works, its security boundaries, browser support, and how it differs from MCP.\n\n## Why this matters\n\nWebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group, not a formal W3C standard. Its imperative API lets pages register JavaScript tools through document.modelContext.registerTool(). Chrome's origin trial also implements a declarative API that turns annotated HTML forms into tools, although that part of the normative draft remains incomplete. WebMCP runs in a live browser context and is separate from the server-oriented Model Context Protocol.\n\nWebMCP is an experimental browser API that lets a website expose structured tools to AI agents through `document.modelContext`\n\n. Instead of reverse-engineering a page from pixels, DOM structure, and click targets, an agent can discover named actions with typed inputs and invoke them through the browser.\n\nThe current specification is a Draft Community Group Report dated July 21, 2026. That status matters: WebMCP is a serious proposal with a Chrome origin trial, but it is not a finished W3C standard or a stable cross-browser feature.\n\n## The Problem WebMCP Tries to Solve\n\nA human can look at a search form, infer what it does, enter a query, and interpret the results. An AI agent has to reconstruct the same interaction from markup, accessibility data, screenshots, or browser automation. That reconstruction is brittle. A changed label, hidden control, or asynchronous state transition can break the flow.\n\nWebMCP gives the page a second interface for the same capability:\n\n- The human gets the normal visual interface.\n- The agent gets a named tool, a description, a JSON Schema input contract, and a structured result.\n- The website keeps its existing validation, authentication, and business logic.\n\nThis is progressive enhancement for agent interaction. The visual page remains the product; WebMCP adds a browser-mediated action surface.\n\n## How the Imperative API Works\n\nThe imperative API registers a JavaScript tool on `document.modelContext`\n\n:\n\n``` js\nif (document.modelContext) {\n  const controller = new AbortController();\n\n  await document.modelContext.registerTool(\n    {\n      name: 'search_posts',\n      title: 'Search posts',\n      description: 'Search published posts by keyword and return up to five matches.',\n      inputSchema: {\n        type: 'object',\n        properties: {\n          query: {\n            type: 'string',\n            description: 'The topic or phrase to search for.'\n          }\n        },\n        required: ['query']\n      },\n      annotations: {\n        readOnlyHint: true,\n        untrustedContentHint: false\n      },\n      async execute({ query }) {\n        return JSON.stringify(searchLocalIndex(query).slice(0, 5));\n      }\n    },\n    { signal: controller.signal }\n  );\n\n  // Abort when the tool should no longer be available.\n  // controller.abort();\n}\n```\n\nThe page controls the implementation. The browser controls discovery and invocation. The current draft defines `getTools()`\n\nand a `toolchange`\n\nevent for in-page discovery. Chrome’s origin-trial documentation also exposes `executeTool()`\n\nso an in-page agent can invoke a discovered tool.\n\nRegistration is dynamic. Passing an `AbortSignal`\n\nlets the page remove a tool when its route, state, or component changes. That is safer than leaving an action registered after the corresponding interface has disappeared.\n\nCross-origin access is closed by default. A page must explicitly expose a tool to secure origins with the `exposedTo`\n\nregistration option, and a caller must request tools from those origins. Cross-origin iframes also require the `tools`\n\nPermissions Policy.\n\n## The Declarative API Turns Forms Into Tools\n\nChrome’s origin-trial documentation also defines a declarative path for HTML forms:\n\n```\n<form\n  toolname=\"createSupportRequest\"\n  tooldescription=\"Submit a customer support request.\"\n>\n  <label for=\"issue\">What went wrong?</label>\n  <textarea\n    id=\"issue\"\n    name=\"issue\"\n    required\n    toolparamdescription=\"A concise description of the support issue.\"\n  ></textarea>\n\n  <button type=\"submit\">Send request</button>\n</form>\n```\n\nThe browser derives a tool schema from the form and its controls. When an agent invokes the tool, Chrome can focus the visible form and populate its fields, leaving the user to submit it. Developers can opt into automatic submission with `toolautosubmit`\n\n, handle agent-triggered submissions through `SubmitEvent.agentInvoked`\n\n, and return a result with `respondWith()`\n\n.\n\nThere is an important standards nuance here. Chrome documents and demos the declarative API, but the normative declarative section in the July 21 Draft Community Group Report is still marked TODO. Implementation availability and specification completeness are not the same thing.\n\nTry the [interactive progressive-enhancement demo](/demos/webmcp-progressive-enhancement.html). Its accessible search form works in every modern browser, while its agent panel exposes the equivalent tool contract and simulates an invocation when the native API is unavailable.\n\n## Annotations Are Hints, Not Security Controls\n\n`readOnlyHint`\n\nand `untrustedContentHint`\n\nhelp an agent reason about a tool:\n\n`readOnlyHint: true`\n\nsays the tool is intended not to change state.`untrustedContentHint: true`\n\nsays the output may contain user-generated or externally sourced content.\n\nNeither field is enforced proof. A dishonest or buggy tool can claim to be read-only while changing data. A supposedly trusted output can still contain malicious instructions. The current specification explicitly identifies prompt injection, tool poisoning, output injection, intent misrepresentation, and privacy leakage as threat classes.\n\nThe right boundary is ordinary application security:\n\n- Recheck authorization inside the operation.\n- Validate inputs in code instead of trusting the schema alone.\n- Keep tools narrow and expose the minimum data required.\n- Require visible user review or confirmation for consequential actions.\n- Treat authenticated read access as sensitive, even when it does not mutate data.\n- Mark external and user-generated output as untrusted.\n- Keep tool names, descriptions, parameters, and outputs concise.\n\nWebMCP can execute within the user’s active browsing context. That is its main advantage and its main risk. Existing session state removes the need to create a second authentication system, but it does not grant an agent broader authority than the user should have in that moment.\n\n## What WebMCP Is Not\n\nWebMCP is easy to confuse with adjacent agent infrastructure. Four boundaries keep the concept precise:\n\n**It is not an MCP server.** WebMCP is a browser API. MCP is a JSON-RPC protocol with stdio and Streamable HTTP transports.**It is not a static discovery manifest.** The current proposal discovers tools from a live browsing context.`/.well-known/webmcp`\n\nis not defined by the draft.**It is not a headless website API.** The browser must visit the page for its tools to become available.**It is not a safety layer.** Tool metadata helps an agent choose, but the website still owns authorization, validation, consent, and error handling.\n\nA product can use WebMCP and MCP together. For example, the browser surface can expose actions tied to the current page while an MCP server exposes account-wide or background operations. They are complementary interfaces with different lifecycles and trust boundaries.\n\n## WebMCP vs. MCP\n\n| WebMCP | Model Context Protocol | |\n|---|---|---|\n| Interface | Browser API on `document.modelContext` | JSON-RPC protocol |\n| Runtime | A live page and browsing context | A separate local or remote server |\n| Discovery | The client visits a page and reads available tools | The client connects to a configured server |\n| Transport | Browser-mediated, no separate protocol transport required | stdio or Streamable HTTP |\n| Authentication | Uses the web application’s active session and controls | The server defines its authentication model |\n| Best fit | Page-scoped actions and visible user flows | Background, account-wide, local, or service-level tools |\n\nThe API name is another useful date marker. Early previews and polyfills used `navigator.modelContext`\n\n. The current draft defines `document.modelContext`\n\n, and Chrome says the navigator surface is deprecated in Chrome 150. Tutorials using the older name target an earlier implementation.\n\n## What I Learned Implementing WebMCP on chudi.dev\n\nMy first chudi.dev implementation used the `@mcp-b/global`\n\npolyfill and its `navigator.modelContext`\n\nsurface. It registered three read-only tools for searching posts, listing posts, and returning author context. I also added a separate `/.well-known/webmcp`\n\nmanifest backed by HTTP routes.\n\nThat experiment exposed a distinction my original article blurred: the browser tools and the HTTP manifest are two independent action surfaces. The former follows an early WebMCP implementation. The latter is custom server-side discovery. Calling both “WebMCP” makes the architecture sound more standardized than it is.\n\nIt also showed why version labels belong beside experimental code. The older [WebMCP + SvelteKit implementation guide](/blog/webmcp-sveltekit-implementation) is evidence of a working polyfill integration, not evidence that its exact API matches the July 21 draft. A current implementation should use a compatibility adapter or migrate to `document.modelContext`\n\n, then test both the enhanced path and the normal site with WebMCP unavailable.\n\n## Browser Support and Production Readiness\n\nChrome documents a WebMCP origin trial beginning in Chrome 149. Developers can also test locally by enabling `chrome://flags/#enable-webmcp-testing`\n\nand use the WebMCP Inspector extension to inspect registered tools. Chrome’s current documentation says the browser must visit the website directly to discover its tools and that headless mode is not supported.\n\nThat is enough for experiments, demos, and controlled trials. It is not enough to make WebMCP a required dependency for a public product. Production code should:\n\n- Feature-detect\n`document.modelContext`\n\n. - Preserve the complete human workflow without WebMCP.\n- Register only tools that are valid for the current page state.\n- Remove stale tools with\n`AbortSignal`\n\n. - Validate and authorize every call inside the implementation.\n- Test expected tasks, incorrect tool selection, malformed input, cancellation, and sensitive-data exposure.\n- Track the dated specification and Chrome implementation separately.\n\n## Why WebMCP Matters\n\nStructured content helps an AI system understand a website. Structured tools help an agent use it. That difference matters for search, support, scheduling, account management, and commerce flows where a wrong click can cost more than a poor summary.\n\nIn [Agent Commerce Readiness](/blog/agent-commerce-readiness-acp-payment-tokens-link-wallets), I argued that machine-readable checkout infrastructure reduces the need for agents to guess through a purchase flow. WebMCP applies the same principle to general web interaction. It also extends the logic behind [answer engine optimization](/blog/aeo-answer-engine-optimization-explained): make meaning explicit where interpretation is expensive.\n\nThe practical stance is neither “ignore it until standardization” nor “rebuild around it now.” Use WebMCP as an optional enhancement, keep its authority narrow, test it against real tasks, and label every implementation with the browser and draft version it targets.\n\n· Frequently asked\n\n## FAQ\n\n### Is WebMCP a W3C standard yet?\n\nNo. The current document is a Draft Community Group Report published by the W3C Web Machine Learning Community Group. It is not on the formal W3C Recommendation track and can still change substantially.\n\n### Does WebMCP require MCP?\n\nNo. A WebMCP tool is registered and executed in a browser context. It does not require an MCP server or MCP transport. A browser or extension may adapt WebMCP tools for an MCP-speaking agent, but that bridge is an implementation choice rather than a WebMCP requirement.\n\n### Which browsers support WebMCP?\n\nWebMCP is not a stable cross-browser feature. Chrome documents an origin trial beginning in Chrome 149 and a local testing flag. Chrome 150 deprecates navigator.modelContext in favor of document.modelContext. Production sites should feature-detect the API and preserve their normal human interface as the fallback.\n\n### Is /.well-known/webmcp part of the WebMCP specification?\n\nNo. The current proposal discovers tools from a page's live browsing context. The explainer records static manifest discovery as an alternative that was considered, not as part of the current API. A site may publish its own manifest or HTTP tool layer, but it should label that layer separately.\n\n### How is a WebMCP tool different from a regular JavaScript function?\n\nA registered tool includes a name, natural-language description, JSON Schema input definition, execution callback, and optional annotations. That metadata makes the action discoverable to an agent. The metadata is descriptive, however, and the tool implementation must still enforce authorization, validation, and business rules.\n\n· Sources & further reading\n\n## Sources & Further Reading\n\n### Sources\n\n[WebMCP Draft Community Group Report webmachinelearning.github.io](https://webmachinelearning.github.io/webmcp/)Primary source for the current API, draft status, permissions model, and security considerations.[Get started with WebMCP developer.chrome.com](https://developer.chrome.com/docs/ai/webmcp)Official hub for Chrome's trial, both APIs, security guidance, testing, and browser limitations.[Model Context Protocol transports modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)Primary source for the JSON-RPC, stdio, and Streamable HTTP comparison with WebMCP.\n\n### Further reading\n\n[I Built a Private MCP Server to Give Claude Memory Across Sessions. Here Is What Broke. /blog/mcp-server-persistent-memory-claude](/blog/mcp-server-persistent-memory-claude)I shipped a private MCP server bridging my knowledge base into claude.ai via OAuth 2.1: the architecture, two bugs the smoke test missed, and the isolation pattern.[I Added WebMCP to SvelteKit: 90 Min, 3 Files. /blog/webmcp-sveltekit-implementation](/blog/webmcp-sveltekit-implementation)Build WebMCP into SvelteKit apps using navigator.modelContext. Learn polyfill setup, tool schemas, and verification in 2026.[How to Use Claude Opus 5: A Failure-Tested Guide /blog/how-to-use-claude-opus-5](/blog/how-to-use-claude-opus-5)Learn how to use Claude Opus 5 with failure replay, effort sweeps, deterministic checks, and a scheduled regression worker.[Agent Commerce Readiness: Preparing for ACP, Shared Payment Tokens, and Link Wallets /blog/agent-commerce-readiness-acp-payment-tokens-link-wallets](/blog/agent-commerce-readiness-acp-payment-tokens-link-wallets)Stripe shipped agent commerce in April 2026. Most sites are not ready to accept transactions from AI agents. The four surfaces operators need to add, the security model behind shared payment tokens, and a working receivable endpoint stub.[The 95% Model Sometimes Lies About Finishing. Anthropic's System Card Documents Both. /blog/fable-5-system-card-capability-and-fabrication](/blog/fable-5-system-card-capability-and-fabrication)Fable 5 hits 95.0% SWE-bench Verified. The same System Card documents fabricated status reports and unverbalized early-stops. Both halves matter.\n\n## What do you think?\n\nI post about this stuff on LinkedIn every day and the conversations there are great. If this post sparked a thought, I'd love to hear it.\n\n[Discuss on LinkedIn](https://www.linkedin.com/in/chudi-nnorukam)", "url": "https://wpnews.pro/news/what-is-webmcp", "canonical_source": "https://chudi.dev/blog/what-is-webmcp", "published_at": "2026-07-17 00:00:00+00:00", "updated_at": "2026-08-02 19:27:38.067112+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-tools", "ai-infrastructure"], "entities": ["W3C Web Machine Learning Community Group", "Chrome"], "alternates": {"html": "https://wpnews.pro/news/what-is-webmcp", "markdown": "https://wpnews.pro/news/what-is-webmcp.md", "text": "https://wpnews.pro/news/what-is-webmcp.txt", "jsonld": "https://wpnews.pro/news/what-is-webmcp.jsonld"}}