WebMCP vs MCP: Which Should You Ship for AI Agents?
WebMCP and MCP both give AI agents tools, but one runs in the user's browser tab and the other on a server. A side-by-side comparison and when to ship each, or both.
Which should you choose?
| If your situation is... | Ship | Why |
|---|---|---|
| Users work in your web app and use an agent built into their browser | WebMCP | No setup for the user; the tools reuse their session and the page's code |
| Users want your product inside Claude, ChatGPT, Cursor, Grok or an IDE | MCP | Those assistants connect to servers; they never load your page |
| Agents run headless, on a schedule or in the background | MCP | WebMCP is designed for a visible tab with a human in the loop |
| The useful action depends on what is on screen right now (a cart, a draft, a selection) | WebMCP | The tool runs in the page and can read and update its state |
| You already have an API and want the widest reach first | MCP, then WebMCP | Directories and registries list MCP servers; WebMCP tools are found only by visiting the site |
| You have both a web app and API customers | Both, from one tool definition | The second surface costs little once tools are defined once |
Short version: MCP brings your product to the user's assistant; WebMCP brings the user's assistant to your product. Most products with a web app and an API benefit from both.
What each one is
MCP (Model Context Protocol) is an open protocol, introduced by Anthropic in November 2024, for connecting AI applications to external tools and data. A client such as Claude, ChatGPT or Cursor connects to an MCP server over stdio (local) or Streamable HTTP (remote), lists its tools and calls them. Remote servers authorize with OAuth 2.1.
WebMCP is a browser API proposed in the W3C Web Machine Learning Community Group. A web page registers tools with
document.modelContext.registerTool(), and the browser offers them to its built-in agent. The tool's code runs in the
page, in the user's tab, with the user's session. It is in origin trials in Chrome (from 149) and Edge (from 150), supported in
ChatGPT desktop and experimental in Brave's Leo.
Side by side
| WebMCP | MCP | |
|---|---|---|
| Where tool code runs | In the web page, in the user's browser | On a server (remote) or the user's machine (local) |
| Who calls it | The agent built into the browser | Any MCP client: chat assistants, IDEs, agent frameworks, scripts |
| Authentication | The page's existing session (cookies, tokens) | OAuth 2.1 for remote servers, or an API key; local servers use environment credentials |
| Setup for the user | None beyond opening the site | Add the server URL or install a plugin, then sign in |
| Discovery | Only by visiting the page | Directories, registries and plugin marketplaces |
| Access to page state | Yes: the tool can read and update the UI | No: it sees only what its API returns |
| Headless use | Not the design goal | Yes |
| Safety hints | readOnlyHint, consequentialHint, untrustedContentHint | readOnlyHint, destructiveHint, idempotentHint, openWorldHint |
| Status | Community Group draft; origin trials | Versioned specification, broad client support |
Authentication is the biggest practical difference
An MCP server has to establish who the user is before it can do anything: an OAuth 2.1 flow with discovery metadata and client registration, or an API key the user pastes. That is real work for you and a real step for the user, but it gives you a durable, revocable credential per connection.
A WebMCP tool skips all of that because the user is already signed in to the page. The flip side is that the agent acts with the
full power of that session. Keep server-side authorization exactly as it is, treat every tool like a public endpoint that an LLM
will call, and mark anything high-stakes with consequentialHint so the browser or agent can confirm with the user.
Discovery: registries versus visits
MCP servers are listed in the official MCP Registry and in client directories, so a user can find and connect yours without ever visiting your website. WebMCP tools are found only when an agent is on your page; Chrome's documentation notes that clients must visit a site directly to know whether it has callable tools. That makes WebMCP a feature of your web app rather than a distribution channel.
Security models
- MCP: scope each credential, show the user what they are approving, rate-limit per connection and let users revoke a connection without revoking everything.
- WebMCP: tools are same-origin by default under the
toolspermissions policy; share with other origins only throughexposedTo; label third-party text withuntrustedContentHint; never ship secrets in page code. - Both: prompt injection is the shared risk. Prefer read-only tools, keep results small and factual, and make write actions explicit.
Shipping both from one definition
At TrendsAGI we define each agent tool once on the server: its name, description, input schema and the API request it stands for.
The MCP server lists those tools to Claude, ChatGPT, Grok and Cursor, and GET /api/agent/tools serves the
same definitions in WebMCP's shape, which our web app registers with the browser. Both paths replay a call through
the same API authentication, plan checks and rate limits, so neither can see more than the other. The second surface took a
catalog endpoint, a session-authenticated call endpoint and a few dozen lines of page code.
Checklist
- List the five or six questions users most want an agent to answer with your product.
- Define one read-only tool per question, with precise names and factual descriptions.
- Expose them over MCP if users live in external assistants or you have API customers.
- Register the same tools with WebMCP in your web app, gated on sign-in.
- Add write tools last, marked as consequential and confirmed in your own UI.
- Record every tool call, including calls to tools that do not exist; those are feature requests written by agents.