WebMCP vs MCP: same direction, different layer
Both tell the web the same thing: declare your capabilities to agents instead of letting them scrape. But they don’t live in the same place, don’t carry the same auth, and shouldn’t carry the same actions.
What they share
The lineage is direct: WebMCP brings MCP’s concepts into the page — typed tools, described by a JSON schema, that an agent discovers then calls. Same “declared, not guessed” philosophy, same tool contract, same family. If you can write an MCP tool, you can write a WebMCP tool.
| Criterion | MCP (server) | WebMCP (in-page) |
|---|---|---|
| Where tools live | On a server (HTTP, remote) | Inside the web page itself |
| Who calls them | Any MCP client: claude.ai, IDEs, headless scripts | The agent embedded in the browser |
| Authentication | OAuth 2.1, scoped tokens | The user’s live session (cookies, cart, account) |
| Best for | Management, reading data, guaranteed server-to-server actions | Acting in the UI: cart, filters, forms |
| Security model | Server-side guarantees (scopes, audit, verified email) | Page context — keep it to reversible actions |
| Works without a browser | Yes | No, by definition |
| Maturity | In production everywhere (Anthropic registry, connectors) | Emerging (W3C draft, Chrome 146 behind a flag, polyfill) |
The direction: both, each in its place
The “which one should I pick” question is malformed: a serious agentic site ends up with both. The MCP server carries what must be guaranteed — verified identity, scopes, audit, signed calls into your systems. The WebMCP page carries what must be fluid — the interface gestures a browser agent performs on the user’s behalf, with their session, in front of their eyes.
The dividing rule fits in one sentence: what is irreversible or sensitive lives server-side; what is reversible and visible can live in the page. That’s the doctrine applied across Animam: the widget is a WebMCP host (your standard actions, usable today via polyfill), and the platform exposes an MCP server — full management by your own agent, a public pre-sale surface, and verified actions that never leave the server.
Go deeper: site actions, WebMCP vs proprietary APIs and verified actions.
FAQ
Will WebMCP replace MCP?
No — they are two floors of the same building. MCP connects an agent to server-side capabilities; WebMCP declares capabilities inside the page that only a browser agent can use. A browser agent can use both on the same site.
Which one does my site need?
With Animam you get both at once: the widget is a WebMCP host (your standard “site actions”, usable today via polyfill), and the platform exposes an MCP server for management and guaranteed server-side actions.
Where should a sensitive action (payment, personal data) live?
Server-side, always. A WebMCP tool runs with the user’s session inside the page — great for filling a cart, dangerous for paying. Animam’s sensitive actions (verified email, signed calls) stay on the server, out of reach of page-content injection.