WebMCP versus MCP, raw APIs and browser automation

These get conflated constantly, usually because they share the word tool. They are not competitors so much as points on a line running from fully headless to fully in-page, and most serious products end up on more than one of them.

The four surfaces, compared on what actually differs

The question that decides it

Who is holding the credential? Everything else follows from the answer.

If a machine acts on its own schedule — a nightly sync, a monitoring job, a partner integration — nobody is signed in, so something must hold a key. That is an API or an MCP server, and the entire apparatus of key issuance, rotation, scoping and revocation comes with it.

If a person is acting through an assistant, they are already signed in, and the browser session already carries it. That is WebMCP's real advantage and it is a security argument rather than a convenience one: no new credential is minted, nothing is stored in an agent's context window, and revoking access is logging out. For a bank or an insurer, that difference is the entire conversation.

Where browser automation still wins

Computer use and browser-driving agents read the screen or the DOM and click. It is slow, expensive and fragile — a redesign breaks it, and every call carries screenshots or a full document through a model. But it works on every site, including the ones that have adopted nothing at all, which is precisely why the major agents still lead with it.

Read that as a warning rather than a reprieve: agents will operate your site whether or not you help them. The choice is between a fragile interpretation of your markup and a stable interface you defined. Only one of those is something you can test.

The discovery gap, which is the real limitation

WebMCP tools exist only while a page is open. An agent cannot learn what you offer without visiting first, and cannot include you in a plan formed before the visit.

That is not a small caveat — it is the difference between the assistant can use this site once the user is on it and the assistant knows this site is an option. Closing it takes a discovery document: a server card at /.well-known/mcp.json, or an OpenAPI description, or an entry in a registry.

What to build, in order

1. Your existing API, documented. Everything downstream calls it. An OpenAPI document with operation IDs and typed schemas is the foundation for all three of the others.
2. WebMCP tools for the in-page journeys. Search, compare, configure, add, book. Cheapest to build, immediate benefit, no credential handling.
3. A discovery document. So agents know you exist before they arrive. Then check your robots.txt does not hide it.
4. An MCP server — only if headless callers genuinely need you. It is a service to run, monitor and secure, and plenty of products never need one.

Note what is not on the list: an in-app assistant of your own. There is a place for those, but the sentiment among people who use agents daily is consistent — they want to bring the assistant that already holds their context, not learn yours. WebMCP is the shape that lets you say yes to that without paying for their tokens.