WebMCP: Websites Declare Structured Tools for AI Agents

WebMCP is a proposed web standard from Google and Microsoft that lets a website declare structured tools for AI agents to call directly - and it's live as an origin trial in Chrome 149. Instead of an agent scraping your DOM and guessing which element is the checkout button, your site registers tools with JSON Schema inputs and outputs, and the agent calls them like any other API.

From Guessing the DOM to Declaring the Contract

The old model of agent-web interaction is screen-scraping: the agent reads the rendered page, infers what elements mean, and hopes it clicked the right thing. That works in demos and falls apart with messy production pages - dynamic layouts, ambiguous labels, A/B tests, dark patterns. WebMCP flips it. The site annotates its own features so agents 'know exactly how to interact' with them. As the source puts it: 'the site declares what it can do, as a set of clean, structured tools the agent can call directly.'

Mechanically it's a JavaScript API: your page registers tools that agents can discover and call, each described with JSON Schema for inputs and outputs. That schema is what reduces hallucinations and misreads - 'the tool is the contract.' If you've ever wired up an MCP server or written OpenAPI specs, this will feel immediately familiar; you're describing capabilities in machine-checkable terms instead of hoping a vision model interprets your UI correctly.

The Part Worth Trying Yourself: Session-Bound Tools

The detail I keep coming back to is that tools run inside the user's existing authenticated session in the browser. No new OAuth flows, no credential handoffs to an agent framework, no scraping around login walls. The agent operates as the user, in the user's browser, and - critically - the site stays in control of what it exposes. You choose which features become tools; everything else stays invisible to automation.

The getting-started cost is genuinely low: there's a ten-minute setup path, Chrome 149 has an origin trial running, and one writeup demonstrated 13 real WebMCP tools working against live sites. If you ship a web app with anything agentic in its roadmap, that's an afternoon experiment, not a quarter-long project.

The Adoption Problem Nobody Solved Yet

Here's my honest read on where this gets annoying: WebMCP only helps if both sides implement it. The site declares tools; the agent discovers them. Every site that hasn't adopted it is still DOM-scraping territory for agents - so early adopters get cleaner automation for their own users' agents while everyone else remains guesswork. That's a classic standardization chicken-and-egg problem, and having Google and Microsoft behind it is about as strong a push as exists.

What this actually points to is a shift in who owns the agent integration surface. Today, agent frameworks own it - they parse your page however they can. Under WebMCP, you own it: you decide what automation surface your product offers, with schemas as guarantees rather than hopes. The real story here isn't 'agents got better at browsing' - it's that websites get to define their own API for agents without building a full public API program.

The caveats are real: it's currently a Community Group draft, not a shipped standard, so schemas you write today may churn. And declaring tools means maintaining them like any other contract - version drift between your UI and your declared tools will be a real failure mode once this sees production traffic.

My plan: run one low-risk feature through the origin trial now - something read-only or easily reversible - and learn what tool-shaped design feels like before this becomes table stakes.