HomeBlogShould your website implement WebMCP now?
    Should your website implement WebMCP now?
    BlogAugust 5, 20266 min read

    Should your website implement WebMCP now?

    Share this article
    Share

    Chrome 149 runs a public origin trial of WebMCP, but only one agent can use it. What the spec does, where it really stands, and which sites should join the trial now.

    Chrome 149 is running a public origin trial of WebMCP, the spec that lets your website hand callable tools to AI agents in the browser. Google announced it on February 10, 2026. Five months later, exactly one agent can use it: Gemini in Chrome.

    That gap between hype and reality is the story. Here is what WebMCP does, where it actually stands, and whether your site should touch it in 2026.

    Status verified July 12, 2026.

    What is WebMCP?

    WebMCP is a proposed web standard that lets a page register JavaScript functions as tools an AI agent can call. Instead of an agent guessing which button to click, your site says: here is searchProducts, here is addToCart, call them with these parameters.

    The API lives at navigator.modelContext. A page registers its tools in script, the browser exposes them, and an agent calls them directly. Engineers from Google and Microsoft wrote the draft inside the W3C Web Machine Learning Community Group.

    The name borrows from MCP, Anthropic's Model Context Protocol, and the idea is the same: give agents typed tools instead of raw pixels. MCP runs on servers. WebMCP runs in the page. If you want the whole protocol family in one map, see our agent readiness stack guide.

    Why do browser agents need this?

    Because clicking is fragile and expensive. Today's browser agents operate sites the way a human does: read the DOM, find the button, click, wait, check what happened. Every redesign breaks them. Every multi-step form multiplies the failure rate.

    A tool call skips all of that. The agent invokes filterFlights({maxPrice: 300}) and gets structured results back. No screenshot parsing, no brittle selectors, fewer wasted tokens. For sites with heavy interactive flows, that is the difference between an agent that completes a booking and one that gives up on step three.

    There is a business angle too. If agents can operate your site reliably, they can finish tasks that end in revenue: bookings, sign-ups, purchases. If they can't, they route to a competitor whose site they can operate.

    Where does the spec actually stand?

    WebMCP is early. Earlier than most coverage admits.

    Four stat tiles showing WebMCP's current footprint: Chrome 149 origin trial, one consuming agent, zero other browser implementations, W3C Community Group draft status

    The timeline so far: Google announced WebMCP on February 10, 2026. The Chromium team filed an Intent to Experiment on May 15, and it was approved three days later. Chrome 149 now runs the public origin trial.

    The spec is a Draft Community Group Report. That is not a W3C standard and it is not on the standards track yet. Firefox and Safari sit in the working group and have shipped nothing. The only consumer of WebMCP tools today is Gemini in Chrome.

    So the honest status is: one browser, one agent, experimental spec. Promising, unproven.

    What would your site actually register?

    Think verbs, not pages. A tool is a function an agent calls to get something done, with typed parameters and a structured result. A flight site might register three: search, hold, and book. A recipe site might register one: search by ingredients and constraints.

    Registration happens in your page script. The shape looks like this:

    navigator.modelContext.registerTool({
      name: 'searchProducts',
      description: 'Search the catalog by keyword, price, and category',
      inputSchema: { /* JSON Schema for parameters */ },
      async execute({ query, maxPrice }) {
        return await api.search(query, { maxPrice });
      }
    });
    

    Two design rules carry over from the MCP world. Describe tools the way you would explain them to a new employee, because the description is what the agent reasons over. And return structured data, not HTML strings, because the agent will feed your result into its next decision.

    The failure mode to avoid is registering your whole API surface. An agent picking from 40 near-identical tools performs worse than one picking from five clear ones. Start with the two or three actions that end in revenue.

    How does WebMCP compare to NLWeb and an MCP server?

    Three protocols now let agents use your site's functionality, and they sit at different distances from the page.

    WebMCP lives in the page. It serves browser agents, works only where the browser supports it, and shines for interactive flows that already run client-side. NLWeb lives on your server as an /ask endpoint that answers natural-language questions with schema.org JSON. An MCP server also lives server-side, exposing tools to any MCP client with no browser involved, which today means the widest reach of the three.

    They are not exclusive. A mature setup might run an MCP server for API access and add WebMCP tools for in-browser flows. But if you are picking one in 2026, the MCP server wins on reach: Claude, and every other MCP client, can use it today, while WebMCP waits on browsers and NLWeb waits on adoption.

    Should your website implement WebMCP now?

    For most sites, no. Watch it. The spec can still change shape, and the audience is limited to Gemini-in-Chrome users.

    Three kinds of sites should consider joining the origin trial early. Sites with complex interactive flows, like booking, configurators, or multi-step checkout, where agent task completion is worth real money. Sites with a Chrome-heavy audience that want first-mover data. And teams that already run an MCP server, since the tool-design thinking transfers directly.

    If that is you, the origin trial costs little: you register tools in script, and browsers without WebMCP simply ignore them. There is no penalty for shipping it early, just limited reach.

    Everyone else should build the boring layers first. Schema markup, markdown for agents, and discovery files pay off today with every AI system. WebMCP pays off later, if the other browsers follow. Our readiness priority list puts it last for a reason.

    How would you know if it's working?

    Track it like a browser feature, not a marketing channel. Watch for three signals: the spec moving to the W3C standards track, a second browser shipping an implementation, and agents beyond Gemini consuming tools.

    Any one of those moves WebMCP from "watch" to "worth adding." Two of them make it urgent. We update the agent readiness stack as these land.

    GenReady already detects WebMCP tool declarations in your pages. It parses your HTML for real script-level declarations and navigator.modelContext registration, and it scores WebMCP as a bonus: detection adds a point, absence never subtracts.


    Want to know if your site already exposes agent tools, or what to build first instead? Run a free GenReady scan — results in under 60 seconds.

    Found this useful?

    Share it with someone who's trying to improve their AI visibility.

    Written by

    GenReady Team

    We help website owners understand how AI crawlers see their content - and how to improve it. Follow us for practical AI readiness tips.

    genready.ai →