WebMCP — MCP in the browser, finally

AI agents interact with websites like clumsy users. They click buttons by guessing CSS selectors, scrape text hoping the HTML structure won’t change, and pray the next design refresh won’t break everything. It’s slow, fragile, and requires constant maintenance.

WebMCP proposes the opposite: instead of letting the agent fumble through the DOM, you give it a structured API. Your site exposes tools, prompt templates, data resources — exactly like a classic MCP server, but directly in the browser. No dedicated backend, no infrastructure to deploy.

The agentic web, but through the DOM. Really?

Today, for an agent to book a flight on your site, it has to find the search field, fill in the dates by guessing the format, click “Search” hoping it’s the right button, then parse the results by scraping HTML. Every step is an inference. Every CSS refactor breaks everything.

WebMCP changes the paradigm: instead of guessing, the agent calls searchFlights({ origin: "CDG", destination: "JFK", dates: [...] }) and receives structured JSON. The site decides what interface it exposes. The agent consumes a clear API, not tag soup.

It’s the same philosophy as MCP (Model Context Protocol), but brought into the browser. MCP allows LLMs to call external tools — typically servers that expose APIs (databases, REST APIs, filesystems). WebMCP applies this model to websites: your frontend app becomes an MCP server itself, and the agent running in Claude Desktop (or any other MCP client) can interact with it through JavaScript-declared tools.

Two APIs for two interaction levels

WebMCP distinguishes two interaction modes, depending on workflow complexity.

Declarative API: for standard actions that can be defined directly in HTML forms. Searches, form submissions, navigation — anything that maps naturally to existing DOM elements. You annotate your forms, and webMCP automatically generates the corresponding tools.

Imperative API: for complex interactions that require custom business logic. Multi-step bookings with server-side validation, conditional workflows, third-party API calls. Here, you register JavaScript callbacks that encapsulate the logic.

A flight search is declarative API. A complete booking with seat selection, baggage addition, multi-step payment — that’s imperative API.

sequenceDiagram
    participant Agent as Agent (Claude Desktop)
    participant Widget as WebMCP Widget
    participant Site as Website
    participant Callback as JS Callback

    Agent->>Widget: calls tool "searchFlights"
    Widget->>Site: forwards parameters
    Site->>Callback: executes business logic
    Callback->>Site: returns results
    Site->>Widget: structured results (JSON)
    Widget->>Agent: MCP response

The agent never has direct DOM access. It goes through the webMCP widget, which serves as a proxy between the MCP client and the JavaScript callbacks you’ve declared.

Four primitives: tools, prompts, resources, sampling

WebMCP supports all MCP primitives.

Tools: functions the agent can call. You register a searchFlights tool with a description and parameter schema. The agent sees this tool in its list, calls it with the right arguments, your callback executes and returns results. No scraping, no guessing.

Prompts: predefined templates the MCP client can use to standardize common queries. Example: a prompt to generate a Git commit message that takes a diff as input and structures the request so the LLM produces a coherent message.

Resources: data exposed by the site for the agent to use as context. Unlike tools (which perform actions), resources are read-only. You can expose the current page content via page://current, or dynamic resources via URI templates (element://{elementId}).

Sampling: the control inversion. Instead of the agent calling tools on the site, the site asks the agent to generate content. Use case: a visual SQL editor where the user describes what they want in natural language, and the site asks the agent to generate the corresponding SQL query. When the site sends a sampling request, webMCP displays a modal to the user for consent. No background generation without human validation.

The widget: an MCP session in the browser

The blue square in the bottom right of the page is the webMCP widget. It’s the entry point to connect an MCP client to the site.

The workflow: you install an MCP client (Claude Desktop, or other), generate a webMCP token, paste it into the widget. The widget establishes a WebSocket connection with the MCP client running locally (on localhost). Once connected, all tools, prompts and resources declared by the site immediately become available in the client. The agent can call them like any MCP tool.

Key difference from classic MCP: here, the MCP server runs in the browser (via JavaScript), not on a remote server. The MCP client connects locally to the widget via WebSocket. The site exposes its capabilities directly from the frontend, without going through a dedicated backend.

This client-side model makes webMCP lightweight to adopt: no need to deploy an MCP server, no need to manage exposed HTTP endpoints. Everything happens between the browser and the local MCP client.

Use cases: e-commerce, support, travel

Chrome highlights three use cases in the webMCP announcement. These aren’t just demo scenarios — they’re workflows where DOM ambiguity costs dearly in errors and user friction.

E-commerce: an agent helping a user buy a product must navigate complex filters (size, color, options), add to cart, manage quantities. With DOM scraping, each step is fragile. With webMCP, you expose an addToCart({ productId, quantity, options }) tool. The agent calls the API, the site controls the logic.

Customer support: creating a support ticket often involves filling a form with technical info (browser, version, logs, config). The average user doesn’t know where to find these. An agent can automatically collect them and pre-fill the ticket via a createSupportTicket tool that retrieves navigator.userAgent, screen resolution, etc.

Travel: searching for a flight is a complex workflow with origin, destination, dates, filters (price, stops, airline), result sorting. With DOM scraping, the agent must guess where filters are, how to apply them, how to parse results. With webMCP, the site exposes searchFlights that returns structured JSON. The agent receives exploitable results, filters them, compares them, and calls bookFlight({ flightId }) to finalize the booking.

These three cases share a common point: the workflow is complex but predictable. These aren’t static sites — they’re rich web apps with business logic. WebMCP allows exposing this logic in a structured way, without the agent having to guess.

Limits and open questions

WebMCP is in early preview. Some limits are obvious, others are open questions that will determine whether this becomes a standard or a technical curiosity.

Security: today, any JavaScript on the page can call mcp.registerTool. If a malicious third-party script executes on your site (compromised browser extension, hacked CDN, XSS injection), it can register tools that exfiltrate data or perform unauthorized actions. No isolation or validation mechanism visible in the current spec. The security model relies on trusting the JavaScript code running on the page.

Discoverability: the current workflow requires the user to manually paste a token into the widget. No automatic discovery mechanism. A possible path: a meta tag in the <head>, or an entry in a JSON manifest, that signals “this site exposes webMCP tools”. But this raises privacy questions: can a site declare it exposes tools without explicit user consent?

Standardization: WebMCP is being developed under the W3C Web Machine Learning Community Group, with participation from Microsoft, Google and other actors. The spec is being written, but nothing guarantees all browsers will implement it. Historically, APIs proposed by a W3C group take time to become cross-browser standards implemented by all vendors.

Adoption: implementing webMCP means maintaining two interfaces: the UI for humans, and the API for agents. Additional development, documentation, tests, maintenance. What’s the economic incentive for an e-commerce site or SaaS platform? If the agent helps the user buy more easily, it might increase conversions. But if the agent enables price comparison or finding alternatives faster, it might also cannibalize sales. Sites that will adopt webMCP first will likely be those with a direct interest in facilitating agentic interactions: support platforms, dev tools, complex SaaS.

WebMCP is available in early preview for participants in the Chrome early preview program. The spec is being written on the W3C repo, and the demo site shows the four MCP primitives in action.

It’s a good direction to move away from DOM scraping. Remains to be seen whether it will become a widely adopted cross-browser standard.