WebMCP Origin Trial: How to Enroll, What to Expect, and Whether It's Worth It

WebMCP is in a public Chrome origin trial running from Chrome 149 through 156. You can enroll your site today and expose WebMCP tools to in-browser AI agents. Here's the honest picture: how enrollment works, what you actually get, what's calling WebMCP tools today, and whether it's worth your time.

What the origin trial gives you

A Chrome origin trial lets you use an experimental browser API on your production site before it's generally available. In exchange for early access, you provide implicit feedback — your usage data helps Chrome's team understand adoption patterns and catch issues before general availability.

For WebMCP specifically, the origin trial gives you access to the navigator.webmcp API in Chrome 149 through 156 on your enrolled origin. You can register tools using the Imperative API, use the Declarative API on HTML forms, and test with the WebMCP DevTools panel in Chrome's Application tab.

What the trial doesn't give you: a production-ready feature. Origin trial APIs can change, be removed, or behave differently than the final API. Code you write for the origin trial may need updates before general availability.

How to enroll

Enrollment is through the Chrome Origin Trials dashboard at developer.chrome.com/origintrials. Search for "WebMCP" and click Register.

You'll get a token — a string that looks like a long base64-encoded value. Add it to every page on your enrolled origin using one of two methods:

HTTP header (recommended):

Origin-Trial: <your-token>

HTML meta tag:

<meta http-equiv="origin-trial" content="<your-token>">

The token is origin-specific — it only works for the exact origin you registered (e.g. https://www.example.com). If you want to enroll a subdomain separately, you need a separate token. Tokens expire with the trial — when Chrome 156 ships, the trial ends and the token stops working.

Verify enrollment by opening Chrome 149+ on your site, opening DevTools → Application → WebMCP. If the panel appears and doesn't show a "not enrolled" warning, you're in.

Registering your first WebMCP tool

Once enrolled, you can register tools in your site's JavaScript. A minimal example for a documentation search tool:

// Check WebMCP support first
if ('webmcp' in navigator) {
  navigator.webmcp.registerTool({
    name: 'search_docs',
    description: 'Search the documentation for a specific topic or question',
    inputSchema: {
      type: 'object',
      properties: {
        query: {
          type: 'string',
          description: 'The search query'
        }
      },
      required: ['query']
    },
    execute: async ({ query }) => {
      const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`)
      const data = await res.json()
      return {
        results: data.results.map(r => ({
          title: r.title,
          url: r.url,
          excerpt: r.excerpt
        }))
      }
    }
  })
}

Check the DevTools panel after registering — you'll see the tool listed with its schema, and you can invoke it manually to test the output before any agent calls it.

Keep descriptions concise and accurate. The description is the only information an agent has about what your tool does and when to call it. Vague descriptions produce unexpected calls; accurate descriptions get the right inputs.

What's actually calling WebMCP tools today

Here's the honest part: as of mid-2026, the demand side hasn't arrived yet.

The primary agent client calling WebMCP tools in the origin trial is Gemini in Chrome — Google's integrated browser agent. It's available in Chrome 149+ when signed into a Google account with Gemini enabled. It's not the dominant AI coding assistant that most developers are actually using.

Claude Desktop, Cursor, Windsurf, and VS Code Copilot — the tools developers use most — are desktop applications that don't run in the browser. They can't call WebMCP tools at all. The @mcp-b/webmcp-local-relay polyfill partially bridges this gap by forwarding WebMCP tools to a local MCP server that desktop clients can connect to, but it requires the user to install and run the relay locally.

An independent audit in May 2026 found that no mainstream agent client calls WebMCP tools in production usage. The supply side (sites registering tools) is warming up; the demand side (agents calling those tools) hasn't arrived at scale.

This isn't a reason to ignore WebMCP — it's a reason to calibrate your expectations. Enrolling now and registering tools is the right preparation move. Spending significant engineering time building complex WebMCP integrations for traffic that doesn't exist yet is probably premature.

The right investment level right now

Given the current demand picture, here's the recommended prioritization:

High value, low effort — do now: Enroll in the origin trial, add the token to your HTTP headers, register 1–2 simple tools (search, navigation, key data lookup). This establishes your site as WebMCP-capable with minimal ongoing maintenance cost, and positions you well if Gemini in Chrome or another client gains traction.

Medium value, medium effort — do if you have capacity: Implement the Declarative API on your existing search and key action forms. This is low-risk because you're annotating existing HTML, not building new functionality.

Low value right now — defer: Building complex multi-step WebMCP action flows, custom DevTools integrations, or deep WebMCP-specific UX. The specification is still changing and the client base is thin. This work will be more valuable in 2027 when the spec stabilizes and more clients ship native WebMCP support.

WebMCP and indexed knowledge: not competing

One common misunderstanding: WebMCP and indexed RAG tools like AgentReady are not alternatives. They solve different problems.

WebMCP tools are good at real-time, live-data, authenticated interactions — check an order status, get a live price quote, search with the user's account context. They run in the browser session where the agent is active.

Indexed knowledge (what AgentReady provides) is good at breadth — covering the full content of your documentation, the range of your product's features, the depth of your API reference. It works from any MCP client, not just browser agents, and it returns cited answers, not just raw data.

The sites that will serve agents best are the ones that implement both: WebMCP for real-time actions, indexed knowledge for documentation depth. You don't have to choose.