WebMCP: your website becomes a tool AI agents can call

WebMCP is an emerging browser standard that lets your website hand an AI agent a list of things it can do - as structured, callable tools - instead of forcing the agent to screenshot the page and guess where to click. It inverts today's brittle model: rather than an agent reverse-engineering your interface pixel by pixel, your site declares its capabilities through a new navigator.modelContext API, and the agent calls them with typed parameters. The efficiency difference is stark - in one demo a flight-booking task dropped from ~500,000 tokens and 30-60 seconds to ~1,000 tokens and 1-2 seconds. If the agentic web is coming, WebMCP is how your site participates in it deliberately rather than getting scraped.

Why this matters now

The agentic web stopped being hypothetical. WebMCP was announced on February 10, 2026 by engineers from Google and Microsoft through the W3C Web Machine Learning Community Group, and it's now in a public origin trial in Chrome 149 (Chrome for Developers). That means you can build against it today, and the direction of travel - browsers becoming a mediation layer between websites and the AI agents acting for users - is now a standards effort, not one vendor's experiment.

The problem it solves is real and expensive. Today an agent "uses" a website the hard way: take a screenshot, infer the layout, guess coordinates, click, re-read the DOM, repeat. It's slow, it burns enormous token budgets, and it shatters the moment you ship a layout change. WebMCP replaces the guessing with a contract.

The mechanism: the site declares, the agent calls

Here's the inversion of control that makes WebMCP work.

Instead of the agent reverse-engineering your UI, your website tells the agent what's possible and the exact parameters each action needs. There are two ways to expose those tools:

• Declarative API - standard actions defined right in your HTML forms. Simple, and it upgrades interfaces you already have.
• Imperative API - for dynamic workflows that need JavaScript: custom validation, API calls, multi-step flows.

Crucially, where standard MCP connects agents to backend servers over JSON-RPC, WebMCP keeps everything in the browser tab. The tools execute in your page's own JavaScript and share whatever session the user is already logged into - so there's no separate API surface to build or secure, and the agent operates with exactly the permissions the user already has.

The part that keeps it safe: the browser mediates

This is the design decision worth underlining. WebMCP is built for collaborative browsing with a human in the loop, not autonomous bots. The browser sits between the agent and the page: it gates what the agent is allowed to do and can prompt the user to approve sensitive actions before they execute. Tellingly, the spec names headless, fully autonomous browsing as an explicit non-goal.

WebMCP isn't a key that lets bots drive your site unattended. It's a way for the site, the browser, and the user to collaborate with an agent - the site offers tools, the browser enforces the guardrails, and the user stays in control.

That framing matters for anyone worried this is just "sanctioned scraping." It's the opposite: a structured, permissioned interface where you decide which actions to expose, and the browser enforces consent.

Our opinion

Our take: WebMCP is early - an origin trial, not a shipping standard - but the direction is right, and it's worth understanding now rather than reacting later. The token and latency numbers aren't a minor optimization; a 500K-to-1K token drop is the difference between agents using your site being economically absurd and being routine. As agentic browsing moves from experimental to default, sites that expose clean tools will be usable by agents and sites that don't will be slow, expensive, and unreliable to automate.

We'd temper the hype with a caution, though: don't rebuild your product around an origin-trial API. The pragmatic move today is to understand the model, keep your core actions expressible as clean forms and functions (which is good design regardless), and be ready to expose them as tools when the standard firms up. This is the browser-side companion to a principle we've already argued for on the server: designing a backend an agent can actually use. Same idea, different layer - give agents a real contract instead of making them guess.

How Ashvara helps

We build web apps, and getting a product ready for the agentic web is squarely our lane: structuring your key actions as clean, typed operations, exposing them through WebMCP's declarative and imperative APIs when it fits, and doing it with the browser-mediated, user-in-the-loop safety the standard is designed around. You end up with a site that's fast and reliable for AI agents to use - without handing over control.

If you want your product ready for AI agents - or just built on solid, agent-friendly foundations - that's our web development work. Talk to us and we'll help you participate in the agentic web on your terms.

Source: Chrome for Developers - WebMCP is available for early preview and WebMCP docs (navigator.modelContext, declarative + imperative APIs, browser-mediated, origin trial in Chrome 149).