What is WebMCP, and should you implement it yet?

How does WebMCP work?

Two halves. A declarative half annotates existing HTML forms so an agent understands what each field wants. A programmatic half registers callable tools through a browser API, so an agent invokes a function rather than simulating clicks.

navigator.modelContext.registerTool({
  name: 'search_products',
  description: 'Search the product catalogue by keyword and category.',
  inputSchema: {
    type: 'object',
    properties: {
      query:    { type: 'string' },
      category: { type: 'string', enum: ['laptops', 'phones', 'audio'] }
    },
    required: ['query']
  },
  execute: async ({ query, category }) => runSearch(query, category)
})

The appeal is obvious: an agent calling a typed function is dramatically more reliable than one inferring your UI from the DOM and hoping the button it found is the right one.

Why is adoption near zero?

It is an origin trial, which means it is not a finished standard, requires registration, works in one browser family, and can change or be withdrawn. Origin trials exist precisely so specifications can fail cheaply, and some do.

So the honest position for most sites in 2026 is to understand it, watch it, and not build on it yet. The exception is if agent-driven interaction is core to your business today — a booking platform or a catalogue with genuine agentic traffic — in which case early implementation buys real advantage and you should accept the churn risk knowingly.

What should I do instead right now?

Get semantic HTML right. It works today, in every browser, for every agent, and it is a prerequisite for WebMCP anyway.

• Every input has a real <label> associated by for and id, not a floating placeholder.
• Correct input types: email, tel, url, date. An agent infers intent from the type.
• autocomplete attributes on anything standard. This is the single highest-value attribute for agents.
• Related fields grouped in <fieldset> with a <legend>.
• Native controls over custom widgets. A custom date picker built from divs is unusable by an agent and usually by a screen reader too.
• Errors announced in text, not conveyed only by a red border.

This is the same work accessibility requires, which is the argument that makes it easy to fund. Agents navigate the accessibility tree, so an accessible form is an agent-usable form almost by definition.

Is Schema.org Action markup an alternative?

Partly, and it is worth adding now. Action types such as SearchAction, OrderAction and ReserveAction declare what can be done on a page rather than only what the page is about. Support is inconsistent, but it is stable structured data rather than an origin trial, so the risk of wasted work is low.

Where this is contested

WebMCP may not survive. Competing approaches exist, browser vendors disagree, and an origin trial is explicitly provisional. We audit for it because Lighthouse does and because early movers deserve credit, but it carries small weight in our rubric and we would not advise anyone to prioritise it over the semantic HTML baseline.

If someone is quoting you for a WebMCP implementation in 2026, ask what happens to that work if the trial ends.