# What is WebMCP (and why it matters) > Source: > Published: 2026-08-26 12:00:00+00:00 [Blog](https://oncroft.net/blog/) · August 27, 2026 · Rich Chetwynd # What is WebMCP (and why it matters) WebMCP lets a website hand AI agents structured tools to call directly, instead of screen-scraping and guessing at buttons. What it is, 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](https://oncroft.net/connect/) — 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](https://oncroft.net/how-it-works/) 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. ## Stake out your croft. Your team's first app could be live before lunch. [Get your croft](https://app.oncroft.net/signup) 7 days free, no card to start. From $24/month - cancel anytime and take everything with you.