WebMCP: Bringing the Model Context Protocol to the Browser

The Model Context Protocol (MCP) transformed the backend AI ecosystem in 2024–2025 by giving language models a standardized way to discover and invoke tools: file systems, databases, APIs, shell commands. Within months, practically every major AI tool supported MCP. But MCP was designed for server-to-server communication; it never solved the problem of giving AI agents access to what's actually in the browser—the live DOM, local state, user interactions, and the web app's own business logic.

WebMCP is the answer. It's a proposed browser standard—currently a Draft Community Group Report published by the W3C Web Machine Learning Community Group on April 23, 2026—that brings MCP-style tool registration directly into the browser's JavaScript runtime via navigator.modelContext. Web pages become MCP servers. AI agents become MCP clients. No backend proxy required.

This article covers how WebMCP works, why it matters for frontend engineers, its current implementation status, and a complete tutorial for exposing your web application as an MCP tool server that any AI assistant can discover and use.

The Problem WebMCP Solves

Consider what happens when a user wants their AI assistant to help them with a task in a web application—say, pulling a customer's order history from a CRM, or submitting a complex multi-step form. Today, the developer has two options:

Option A: Build a backend MCP server. Create a Node.js or Python service that exposes your application's data via MCP tools. Works well, but requires deploying and maintaining a separate server, keeping it in sync with your frontend state, and handling authentication separately.

Option B: Give the agent direct API access. Expose REST or GraphQL endpoints and teach the agent to call them. Exposes your entire API surface, requires careful auth scoping, and the agent still can't see or interact with the rendered UI.

Neither option lets the agent interact with what the user is actually seeing. WebMCP enables a third option: the web page itself exposes tools, the AI client discovers them, and everything happens in the browser—with the page's existing auth, state, and access controls already in place.

How WebMCP Works

The Core API Surface

WebMCP centers on two objects on the navigator global:

navigator.modelContext — The stable, spec-owned surface for registering and unregistering tools. Every web page with WebMCP support uses this.

navigator.modelContextTesting — A companion surface for testing and inspection, primarily used by browser DevTools and test harnesses. Not part of the stable consumer API.

Registering a Tool

navigator.modelContext.registerTool({
  name: 'get-customer-orders',
  description: 'Retrieve order history for the currently logged-in customer. Returns up to 50 recent orders.',
  inputSchema: {
    type: 'object',
    properties: {
      limit: {
        type: 'number',
        description: 'Maximum number of orders to return (1–50)',
      },
      status: {
        type: 'string',
        enum: ['all', 'pending', 'shipped', 'delivered', 'cancelled'],
        description: 'Filter orders by status',
      },
    },
  },
  async execute({ limit = 20, status = 'all' }) {
    const orders = await fetchOrdersFromStore({ limit, status });
    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify(orders, null, 2),
        },
      ],
    };
  },
});

That's it. Once registered, any AI client with WebMCP support can discover this tool, read its description and schema, and invoke it—just as if it were an MCP server tool.

Unregistering a Tool

navigator.modelContext.unregisterTool('get-customer-orders');

No-op if the tool isn't registered. Useful for cleanup in component unmount effects, or when a user navigates away from the part of your app that provides the tool.

Feature Detection

Always check for the API before using it—browser support is still limited:

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({ /* ... */ });
} else {
  console.warn('WebMCP not supported in this browser. Consider a polyfill.');
}

The Declarative API

Beyond the imperative JavaScript API, WebMCP also supports a declarative form annotation approach, where HTML forms can expose themselves as tools:

<form
  data-mcp-tool="submit-support-ticket"
  data-mcp-description="Submit a support ticket for the currently logged-in user"
  method="post"
  action="/api/tickets"
>
  <label>
    Subject
    <input name="subject" type="text" data-mcp-param-description="Brief summary of the issue" />
  </label>
  <label>
    Priority
    <select name="priority" data-mcp-param-description="Issue urgency">
      <option value="low">Low</option>
      <option value="medium">Medium</option>
      <option value="high">High</option>
    </select>
  </label>
  <button type="submit">Submit</button>
</form>

The browser reads the data-mcp-* annotations and automatically registers a corresponding tool. When an AI agent invokes it, the browser fills in the form and submits it. This is a significant ergonomic improvement for forms-heavy applications: you describe the tool in HTML, and the browser handles the tool registration plumbing.

Note: The declarative API's attribute names are not yet finalized in the spec. Use them cautiously in production, and watch the W3C discussion thread for updates.

The Testing Surface

navigator.modelContextTesting is designed for inspection and test harnesses, not production use. It exposes:

// List all registered tools (metadata only, no execute functions)
const tools = navigator.modelContextTesting?.listTools();
// Returns: ModelContextTestingToolInfo[]
// Note: inputSchema is returned as a JSON string, not a parsed object