What is WebMCP? Giving AI agents real buttons instead of guesswork

WebMCP lets a web page hand an AI agent a set of typed, described tools it can call directly. Instead of the agent inspecting your DOM and inferring that the input with id="q" is probably a product search, you tell it: there is a tool called searchProducts, it takes a query string and an optional maxPrice number, and here is what it does.

It is the difference between handing someone a control panel and asking them to guess which wires to touch.

Accurate as of July 2026. WebMCP is running as a Chrome origin trial and is not yet a shipped web platform feature.

The problem it solves

Today an agent operating your site is doing screen scraping with better manners. It loads the page, reads the accessibility tree and the markup, forms a theory about which elements do what, and then acts on that theory.

This works more often than you might expect, and it fails in ways that are difficult to predict. A redesign that moves your search box breaks it. A modal that appears on the third visit breaks it. An input labelled only by a placeholder and an icon is ambiguous. None of these are bugs in your site; they are just the cost of inference.

WebMCP removes the inference. You declare what is available, and the agent calls it.

What it looks like

Tools are registered in page script:

navigator.modelContext.provideContext({
  tools: [
    {
      name: 'searchProducts',
      description: 'Search the product catalogue by keyword and optional maximum price.',
      inputSchema: {
        type: 'object',
        properties: {
          query:    { type: 'string', description: 'What to search for' },
          maxPrice: { type: 'number', description: 'Maximum price in GBP' }
        },
        required: ['query']
      },
      async execute({ query, maxPrice }) {
        const results = await storefront.search(query, { maxPrice })
        return { content: [{ type: 'text', text: JSON.stringify(results) }] }
      }
    }
  ]
})

Three parts matter, and they are not equally weighted.

The name is an identifier. The input schema is a contract, and it is what stops an agent passing a string where you wanted a number. The description is the part people skip and the part that decides whether your tool ever gets used. An agent choosing between six available tools reads the descriptions. A tool described as "search" gives it nothing to go on. A tool described as "Search the product catalogue by keyword and optional maximum price" tells it exactly when this is the right call.

If you write nothing else carefully, write the descriptions.

Where it stands

WebMCP is co-authored by Microsoft and Google and incubated in a W3C community group. It is running as a public Chrome origin trial from Chrome 149 through 156, with shipping targeted at Chrome 157.

An origin trial means real users on real Chrome can use it on sites that opt in, but the API can still change and it is not on by default everywhere. That places WebMCP meaningfully earlier than UCP, which already has merchants serving live profiles in production.

The rename that broke the guides

If you are following a tutorial written earlier in 2026, check the entry point before you debug anything else.

The API that tool registration hangs off was renamed during incubation. Older material shows the previous entry point, and code written against it does not error loudly. It simply registers nothing, and your page looks to an agent exactly like a page with no tools at all.

This is a small, specific instance of the general problem with building against young specifications: the failure is silent. There is no console warning telling you that the object you called is no longer the one that matters. You need to either check against the current specification or test your contracts in CI so a change gets caught by a build rather than by nobody.

How it differs from UCP

These two get confused because they arrive at the same time and both involve agents. They operate at different moments.

| | UCP | WebMCP | |---|---|---| | When | Before the agent arrives | While the agent is on the page | | What | A document describing your business | Functions your page exposes | | Where | /.well-known/ucp on your domain | Registered in page script | | Scope | Commerce | Any site | | Maturity | Live profiles in production | Chrome origin trial |

The one line version: UCP is what you say about your business before an agent visits. WebMCP is what your page lets it do once it is there.

They are complementary rather than competing. A shop might publish a UCP profile so agents can discover it at all, and expose WebMCP tools so an agent already on the page can filter a catalogue without fighting the interface.

What to expose, and what not to

The instinct is to expose everything. Resist it.

Good candidates are read-heavy operations where inference is unreliable and the value is high: searching a catalogue, filtering by attributes, checking stock for a variant, looking up delivery options for a postcode. These are things agents genuinely struggle to drive through a UI, and getting them wrong is annoying rather than dangerous.

Think hard about anything that writes. Adding to a basket is reasonable. Placing an order, changing an address, or cancelling something deserves more care, because a tool description is an invitation and the agent on the other end may be acting on a loosely worded instruction from a person who is not watching closely.

Do not expose anything you would not put behind a public API. A declared tool is a documented, machine-readable entry point into your application. Everything you already believe about authentication, authorisation and rate limiting still applies. WebMCP does not add a security boundary; it makes your existing ones more discoverable.

Common mistakes

Registering after the agent has looked. If your tools are registered inside a late-firing callback, an agent that inspects the page earlier sees nothing. Register as early as you reasonably can.

Descriptions written for yourself. updateQty means something to you. To a model deciding between tools, it is close to noise. Write the description as if for a competent new colleague who has never seen your product.

Schemas that lie. Marking a field optional that your handler actually requires produces a confusing failure at call time. The schema is a contract, and the agent will hold you to it.

Assuming a static scan can verify it. Because registration happens in page script, you cannot confirm your tools by looking at your HTML source. It has to be evaluated in a real browser. That is precisely why our WebMCP checker runs a browser tier rather than pattern matching your markup.

Should you do anything yet?

For most sites, not urgently. WebMCP is still a trial, and building against an API that is explicitly still moving has a cost.

What is worth doing now is smaller and cheaper:

1. Understand the model, because the shape of it is unlikely to change even if the surface does. Declared tools with typed schemas and natural language descriptions is where this is going.
2. Notice which of your operations are hard to drive through a UI. Those are your eventual tool list, and knowing them costs nothing.
3. Watch the trial dates. Chrome 157 is the one to care about.

If you sell things, UCP is the more pressing of the two, because it is live now and you may already have an integration you have never inspected.

Read next

• What is UCP? — the commerce side, and the one already in production
• How agents see your website — what an agent actually does on arrival
• AI crawlers vs AI agents — why the two need different rules