🤖 AI & Agents · 10 min read

WebMCP vs MCP: What Each One Does and When to Use Both

WebMCP and MCP are not competing standards, and you do not have to pick one. MCP connects an AI client to backend systems through a server that runs outside the browser. WebMCP lets a web page hand its own tools to the browser's built-in agent while a user has that page open. Chrome's documentation states outright that WebMCP is not an extension or a replacement of MCP.

The question comes up because both names describe one idea: a machine-readable way for software to say what it can do. Chrome's comparison page opens with the exact question developers ask, whether WebMCP will replace MCP, and then answers it. What follows is that answer with the mechanics filled in, plus the tool output we measured on a site running both layers.

Short answer: they are partners, not opponents

Chrome explains the split with an analogy: a company's customer service call center against an in-store expert. The call center is reachable through any channel at any time and looks things up behind the scenes. The in-store expert only exists on your premises, in this case your page, and can see what the customer is looking at right now.

The documentation then says it in one line each: MCP is for backend, WebMCP is for frontend. The deciding factor is not capability, it is location. An MCP server is a process or a hosted service. A WebMCP tool is a live tab, and only while that tab stays open.

What MCP is

Model Context Protocol is an open protocol that connects LLM applications with external data sources and tools. Two facts explain most of the differences you will read about.

• Format and transport. Messages are JSON-RPC 2.0, UTF-8 encoded. The specification defines two standard transports: stdio, where the client launches the server as a subprocess, and Streamable HTTP. Connections are stateful and the two sides negotiate capabilities during initialization.
• Structure.The spec names three roles: a host, which is the LLM application; clients inside that host; and servers that provide context and capabilities. Servers can offer resources, prompts and tools. Only the third one is the "call this function" part people usually mean.

The current specification is revision 2025-06-18, and the project publishes SDKs for Rust, Python and TypeScript, among others. In practice an agent connects to a server that may be running on your own machine or on someone else's, and that server's tools are available in every conversation the client has, whether or not your website is open at the time.

What WebMCP is

WebMCP is a proposed browser standard. Chrome ships it as an origin trial from Chrome 149, which is why trying it locally means enabling the flag at chrome://flags/#enable-webmcp-testingrather than installing anything. Chrome describes the scope narrowly: two APIs that interact with a browser's built-in agent, implemented either in JavaScript or with HTML attributes.

The declarative API adds attributes to a form you already have. toolname names the tool, tooldescription says what it does, and individual fields can carry toolparamdescriptionso the parameters arrive with sensible names. Chrome's documentation notes that removing either toolname or tooldescription unregisters the tool, which makes a copy edit a breaking change.

The imperative API is a JavaScript call, document.modelContext.registerTool, which takes a name, a description, an inputSchema and an execute function. Long-running work can receive an AbortSignal, and as of Chrome 153 a tool can be unregistered without cancelling executions already in flight.

Two properties of WebMCP matter more than the API shape. Tools are ephemeral: Chrome says they exist only while your page is open, so closing the tab ends the agent's access. And they are DOM-aware: a WebMCP tool runs against the live page, including the session state and elements that exist only in that tab.

The comparison, from Chrome's own table

Rather than paraphrase it, here is the table Chrome publishes on its comparison page, with the six rows that page uses.

Chrome's recommendation is to run both. The MCP server carries core business logic, data retrieval and background tasks. WebMCP is the last step, the connection between an agent and the page in front of the user. Read from the table, the pair is additive rather than alternative.

What we measured on a live site

Our own site runs the WebMCP origin trial, and we check it instead of assuming it works. The token in our response headers decodes to this payload:

{"origin":"https://nocodecsv.com:443","feature":"WebMCP","expiry":1794873600}

1794873600 is 17 November 2026 in Unix time, and it is the moment the token stops being valid. Origin trials are time-boxed by design, so a declaration that passes a check today can fail next quarter without anyone touching the page. We put that date in our own re-check list for exactly that reason.

Next we loaded our tool pages in a Chromium build started with the WebMCP testing flag and awaited navigator.modelContext.getTools(). The browser returned the following, which is the raw material for the rest of this section:

The empty parameter lists are the interesting half. A tool whose only input is a file picker arrives in the agent's tool list with no parameters at all, because the file input does not become a callable argument. That is why two of our tools are text-shaped: an agent can pass CSV or JSON content as a string even when it cannot attach a file. In an MCP server this problem does not exist in the same form, because the tool takes the arguments its schema declares and the server does the file handling on its own side. In the browser, handing a file from agent to page has no declared path yet, and we have not found a workaround that survives a re-test.

We also loaded two pages with no declarations, /tools/csv-analyzer and /agent-ready. Both returned zero tools, which is the correct behaviour rather than a fault: nothing declared, nothing exposed. If you are auditing your own site, a page that returns tools you did not know about is the result worth chasing.

When to use which

• The action must work while your site is closed.That is MCP. Scheduled jobs, lookups on a phone with no browser tab open, anything an assistant does on the user's behalf before they decide to visit you.
• The action depends on the live page or the signed-in session. That is WebMCP, and only WebMCP, because an MCP server has no view of the DOM a user is looking at.
• An assistant should know what your site offers before deciding to send someone there. Neither of the above. That is a static file an agent can read without executing your page, which is what agent-tools.json is for.
• You only need your content read and cited. Then you need crawler policy and a reading list, not an API. Our llms.txt guide covers that side.

What WebMCP still cannot do

Five limits, four of which come from Chrome's own documentation and one from our test above.

1. Headless browsing. Chrome lists it as a limitation and says the API is primarily designed for local browser workflows with a human in the loop.
2. Complex interfaces. The same page warns that highly complex sites likely need refactoring or added JavaScript before declarations are worth writing.
3. Tab lifetime. Close the tab and the tools are gone. There is no server-side copy of what the agent was allowed to do.
4. File handoff. A file picker contributes no parameters, as the table above shows.
5. Sign-in walls. A tool that only exists after authentication is invisible to an agent browsing signed out. We measured that on our own dashboard, where an anonymous load redirects to a sign-in page with no tools registered.

None of these is a reason to skip the layer. They are reasons to describe what you publish accurately instead of optimistically. We wrote the declaration mechanics out in What Is WebMCP? if you want the attribute-level version.

Frequently asked questions

I build this layer for other sites — llms.txt, agent-tools.json, WebMCP declarations — and verify each one against the live pages. Details at /agent-ready.