WebMCP — browser-native tools for agents

The W3C Web Machine Learning Community Group is incubating WebMCP, a browser API that lets web pages register structured tools for in-browser AI agents to call directly via a JavaScript API, eliminating the need for server-side MCP plumbing. The specification.website already implements WebMCP, registering tools like search_spec and list_topics at build time, enabling agents to search and read the spec without a remote MCP server. This approach allows teams to reuse the same tool vocabulary as server-side MCP, access authenticated user sessions, and avoid new transport infrastructure.

WebMCP — browser-native tools for agents WebMCP lets a page register tools that an in-browser AI agent can call directly, using a navigator.modelContext JavaScript API. It turns a site into an agent surface without server-side MCP plumbing. What it is WebMCP is an emerging browser API that lets a page register structured tools — named functions with input schemas — that an AI agent running inside the same browser a sidebar assistant, a built-in browser agent, an extension can invoke directly. The shape mirrors Model Context Protocol /spec/agent-readiness/mcp-and-tool-discovery/ tools, hence the name: it is MCP, but the transport is the JavaScript heap instead of HTTP+JSON-RPC. The proposal is incubated in the W3C Web Machine Learning Community Group https://webmachinelearning.github.io/webmcp/ . The current spec surface is document.modelContext ; earlier drafts and some shipping implementations exposed it as navigator.modelContext and a portable script feature-detects both. A page registers a tool by calling registerTool { name, description, inputSchema, annotations, execute } . The browser exposes registered tools to the local agent; the agent calls execute and gets a result back, all without leaving the tab. js const mc = typeof document == 'undefined' && document.modelContext || typeof navigator == 'undefined' && navigator.modelContext ; mc?.registerTool { name: 'search docs', description: 'Search the documentation for a query.', inputSchema: { type: 'object', properties: { query: { type: 'string' } }, required: 'query' , }, annotations: { readOnlyHint: true }, async execute { query } { const res = await fetch /api/search?q=${encodeURIComponent query } ; return { content: { type: 'text', text: await res.text } }; }, } ; This site ships it. Every page on specification.website loads /webmcp.js /webmcp.js , which registers search spec , list topics , get topic , open search , and open checklist tools — generated at build time from the same content collection that powers the rest of the site. An in-browser agent can search and read the spec without going through the remote MCP server /spec/agent-readiness/mcp-and-tool-discovery/ . Why it matters Same vocabulary as server-side MCP. A team that already builds MCP tools on the server can expose the same shapes in the browser without re-modelling. Sees the logged-in user. A browser-side tool runs inside the user’s authenticated session, including cookies, IndexedDB, and any per-tab state. A server MCP server has none of that without explicit auth plumbing. No new transport. Nothing to host, nothing to scale, no auth headers to wire up. The browser is the transport. Composes with MCP. A site can ship both: an HTTP MCP server for headless agents and a WebMCP surface for in-browser agents. Same tool names, same schemas, same intent. The API is early — implementations are shipping behind flags and via polyfill. Treat WebMCP as optional until at least one major browser exposes it without a flag. The cost of being early is low; the design follows MCP closely so most code will port forward. How to implement Register tools at page load , after navigator.modelContext is feature-detected. If the API is absent, do nothing — never throw. Mirror your server-side MCP tools. If you already publish search docs on an HTTP MCP server, register a tool with the same name, description, and input schema in the browser. An agent that knows the server-side tool will recognise the browser one immediately. Use the to declare safety properties: annotations field readOnlyHint: true for tools that do not mutate state, destructiveHint: true for ones that do. The agent uses these to decide whether to confirm with the user. Pick when the tool returns a single result rather than streaming. Streaming is supported but adds complexity that most page tools do not need. mode: 'summarize' Keep A tool is a thin call into existing site functionality search, navigation, account actions , not a bespoke pipeline. execute small. Document the tools. Add them to your agent skills index /spec/agent-readiness/agent-skills-discovery/ so agents that read the site’s discovery surfaces — not just ones already in the browser — know they exist. Common mistakes - Registering tools that bypass the site’s own access controls. A WebMCP tool runs as the logged-in user; treat it like any other JavaScript-callable action and apply the same authorisation checks server-side. - Forgetting feature detection. navigator.modelContext does not exist in most browsers yet. Guard every call. - Designing tools that only make sense in the browser. If a server-side MCP server can do the same job, ship both — agents should be able to use whichever transport they have. - Treating annotations as cosmetic. readOnlyHint and destructiveHint change agent behaviour; declare them honestly. Verification typeof navigator.modelContext?.registerTool === 'function' in a console on a supporting browser.- The browser’s agent UI lists your registered tools by name and description. - Calling a registered tool from a test agent returns a well-formed MCP-shaped result { content: ... } . - If you ship a parallel HTTP MCP server, the tool names match across both surfaces. Related topics Sources & further reading WebMCP — W3C Web Machine Learning Community Group https://webmachinelearning.github.io/webmcp/ — W3C WebML CG webmachinelearning/webmcp on GitHub https://github.com/webmachinelearning/webmcp — W3C WebML CG Model Context Protocol — Tools https://modelcontextprotocol.io/specification/2025-11-25/server/tools — MCP