{"slug": "webmcp-browser-native-tools-for-agents", "title": "WebMCP — browser-native tools for agents", "summary": "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.", "body_md": "# WebMCP — browser-native tools for agents\n\nWebMCP 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.\n\n## What it is\n\nWebMCP 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.\n\nThe proposal is incubated in the [W3C Web Machine Learning Community Group](https://webmachinelearning.github.io/webmcp/). The current spec surface is `document.modelContext`\n\n; earlier drafts (and some shipping implementations) exposed it as `navigator.modelContext`\n\nand a portable script feature-detects both. A page registers a tool by calling `registerTool({ name, description, inputSchema, annotations, execute })`\n\n. The browser exposes registered tools to the local agent; the agent calls `execute()`\n\nand gets a result back, all without leaving the tab.\n\n``` js\nconst mc =\n  (typeof document !== 'undefined' && document.modelContext) ||\n  (typeof navigator !== 'undefined' && navigator.modelContext);\n\nmc?.registerTool({\n  name: 'search_docs',\n  description: 'Search the documentation for a query.',\n  inputSchema: {\n    type: 'object',\n    properties: { query: { type: 'string' } },\n    required: ['query'],\n  },\n  annotations: { readOnlyHint: true },\n  async execute({ query }) {\n    const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);\n    return { content: [{ type: 'text', text: await res.text() }] };\n  },\n});\n```\n\n**This site ships it.** Every page on `specification.website`\n\nloads [ /webmcp.js](/webmcp.js), which registers\n\n`search_spec`\n\n, `list_topics`\n\n, `get_topic`\n\n, `open_search`\n\n, and `open_checklist`\n\ntools — 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/).\n\n## Why it matters\n\n**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.\n\nThe API is early — implementations are shipping behind flags and via polyfill. Treat WebMCP as `optional`\n\nuntil 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.\n\n## How to implement\n\n**Register tools at page load**, after`navigator.modelContext`\n\nis feature-detected. If the API is absent, do nothing — never throw.**Mirror your server-side MCP tools.** If you already publish`search_docs`\n\non 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`\n\nfield`readOnlyHint: true`\n\nfor tools that do not mutate state,`destructiveHint: true`\n\nfor 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'`\n\n**Keep** A tool is a thin call into existing site functionality (search, navigation, account actions), not a bespoke pipeline.`execute()`\n\nsmall.**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.\n\n## Common mistakes\n\n- 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.\n- Forgetting feature detection.\n`navigator.modelContext`\n\ndoes 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.\n- Treating annotations as cosmetic.\n`readOnlyHint`\n\nand`destructiveHint`\n\nchange agent behaviour; declare them honestly.\n\n## Verification\n\n`typeof navigator.modelContext?.registerTool === 'function'`\n\nin a console on a supporting browser.- The browser’s agent UI lists your registered tools by name and description.\n- Calling a registered tool from a test agent returns a well-formed MCP-shaped result (\n`{ content: [...] }`\n\n). - If you ship a parallel HTTP MCP server, the tool names match across both surfaces.\n\n## Related topics\n\n## Sources & further reading\n\n[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", "url": "https://wpnews.pro/news/webmcp-browser-native-tools-for-agents", "canonical_source": "https://specification.website/spec/agent-readiness/webmcp/", "published_at": "2026-07-16 00:00:00+00:00", "updated_at": "2026-07-16 11:29:46.116198+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["W3C Web Machine Learning Community Group", "WebMCP", "specification.website", "Model Context Protocol"], "alternates": {"html": "https://wpnews.pro/news/webmcp-browser-native-tools-for-agents", "markdown": "https://wpnews.pro/news/webmcp-browser-native-tools-for-agents.md", "text": "https://wpnews.pro/news/webmcp-browser-native-tools-for-agents.txt", "jsonld": "https://wpnews.pro/news/webmcp-browser-native-tools-for-agents.jsonld"}}