What is WebMCP (and why it matters)

AI agents are learning to use the web on your behalf — booking a flight, filling a form, pulling a number out of a dashboard. The trouble is how they do it today: they take screenshots, parse raw HTML, and guess which button does what. It’s slow, expensive, and it breaks the moment a site changes its layout.

WebMCP is the fix. It’s a new browser standard that lets a website hand an AI agent a clean set of tools to call directly — no guessing required.

What WebMCP is

WebMCP (Web Model Context Protocol) is a proposed web standard, incubated at the W3C by Google’s Chrome team and Microsoft’s Edge team. It builds on the same idea as MCP — the Model Context Protocol that assistants like Claude and ChatGPT already use to talk to tools — but brings it into the browser, to the front end of a web page.

Instead of an agent looking at your page and trying to work out what’s clickable, the page simply tells it: “Here’s a tool called searchFlights. It needs an origin, a destination, and a date. Call it, and I’ll give you structured results.” The agent discovers the tools, reads their definitions, and calls them — replacing a long chain of clicks with a single, reliable function call.

How it works

A site exposes its tools in one of two ways:

Annotate your HTML. Add attributes like toolname and tooldescription to an existing form, and the browser turns its fields into a structured schema an agent can understand. Minimal effort for simple things.
Register tools in JavaScript. Use the new navigator.modelContext API to declare tools with a name, a description, an input schema, and a function to run. This handles richer, dynamic cases, and tools can appear or disappear as the page state changes.

Two details make it neat. It runs inside the browser tab, so it inherits the session you’re already in — your cookies and single sign-on — rather than needing a separate login. And because the tools are declared by the site itself, they don’t break when the visual design changes.

WebMCP vs “regular” MCP

They’re complementary layers of the same idea:

Regular MCP runs on a separate server that an assistant connects to — this is how you build apps on Croft, by pointing Claude or ChatGPT at your croft’s MCP endpoint. It covers tools, resources, and prompts.
WebMCP runs in the page, front-end, and (for now) covers tool-calling only. It’s how a running web app makes itself usable by an agent in the browser.

One is about building and managing software; the other is about letting an agent operate the software once it’s live.

Why it’s useful

For the people using agents: the agent actually gets things done — searching a catalogue, starting a checkout, creating a support ticket, updating a dashboard — quickly and without misclicks.

For whoever owns the site: you become usable by the wave of agentic browsers now arriving (Chrome’s auto-browse, OpenAI’s Atlas, and others). Those tools are the consumers; WebMCP is the infrastructure a site implements to be used well by them. It’s faster and cheaper than being screen-scraped, it doesn’t shatter on a redesign, and it opens your product to a new kind of visitor: an agent working for a real customer.

Where it’s at (be realistic)

It’s early. WebMCP is a W3C Community Group draft, not a finished standard, and it’s shipped as an early preview in Chrome 146 behind a flag. The spec will change, it’s tools-only for now (no resources or prompts yet), and because it leans on your browser session for auth, sensitive actions need careful thought. This is a “start prototyping and watching” moment, not a “bet production on it today” one.

What it means for the apps you build

Here’s the part that matters if you build software. The agentic web isn’t only about chat any more — it’s coming to the front end of your apps. And that raises a question: when the standard settles, will your apps be able to adopt it?

If your app lives inside a closed platform, you wait for that platform to add it — if it ever does. The apps you build on Croft are different: they’re real web apps that are yours — your code, on a server that’s yours. So when WebMCP stabilises, you can add a handful of tool declarations to your internal tools and make them agent-ready on your own timeline, no permission required. And on the build side, Croft is already MCP-native.

The web is quietly growing a machine-readable layer alongside the human one. WebMCP is how that layer gets built — and owning your apps is how you make sure you can be part of it.

See how Croft works → · Connect an assistant over MCP →