🤖 AI & Agents · 8 min read

What Is WebMCP? How a Website Hands Its Tools to an AI Agent

WebMCP is a proposed browser standard that lets a website declare its own tools, so an AI agent inside the browser can call a defined function instead of guessing which button to click ( Chrome for Developers). It comes in two forms: HTML attributes on an ordinary form, and a JavaScript API for interactions that cannot be expressed as a form. That is the whole idea. Everything else is detail about how a form becomes a tool, what an agent sees when it asks the browser what your page can do, and how far the preview actually goes today.

The question shows up in several forms. People type “what is webmcp”, “webmcp vs mcp” and “how does webmcp work”, which are three ways of asking the same thing. This page answers all three, and adds something the documentation cannot: the tool list we read back from a live site, including the part that does not work yet.

What is WebMCP?

WebMCP defines how a page tells a browser agent what it can do. Instead of the agent inferring actions from the rendered interface, the site publishes a machine-readable list of tools with names, descriptions and parameter schemas. The documentation describes two APIs for doing that ( developer.chrome.com/docs/ai/webmcp):

Chrome's documentation lists the declarative API as an origin trial. That matters for anyone planning work around it: the API is live for enrolled origins, not for the web at large, and it is not something you can rely on a random visitor's browser to implement.

How does the declarative API actually work?

You annotate a form you already have. Two attributes are required, and the documentation is blunt about the consequence of leaving one out: removing either toolname or tooldescription unregisters the tool. The optional toolparamdescriptionattribute goes on individual fields when the browser cannot work out what a field means. Without it, the browser uses the field's <label>, and if there is no label it falls back to aria-description.

<form toolname="splitLargeCsv"
      tooldescription="Splits a CSV file that is too large for Excel.">
  <label for="rows">Rows per file</label>
  <input type="number" name="rows" id="rows"
         toolparamdescription="How many data rows each output file should hold.">
  <button type="submit">Split</button>
</form>

The browser turns that markup into JSON. For a form with text, number and select inputs, the generated tool carries an inputSchema whose properties are the named fields, plus a requiredarray for the ones marked required. That is the mechanism that makes an agent's call predictable rather than a click simulation.

Three more pieces of the declarative API are worth knowing, because they decide how the interaction ends. toolautosubmit lets the model submit the form instead of waiting for a person to press the button. The SubmitEvent interface gains an agentInvoked boolean, so a site can tell an agent submission from a human one, and a respondWith(Promise)method that returns a value to the model as the tool's output. On the page there are toolactivated and toolcancel events on window, and the CSS pseudo-classes :tool-form-active and :tool-submit-active for showing a user which form an agent is currently filling ( declarative API reference).

What did we measure on a live site?

Documentation tells you what should happen. So we enrolled our own domain in the origin trial and read the tools back out of the browser. These are the results from 18 September 2026, on nocodecsv.com:

• The served page carries an origin-trial response header. Decoded, its payload reads {"origin":"https://nocodecsv.com:443","feature":"WebMCP","expiry":1794873600}, which is 17 November 2026 in UTC. The enrollment is per origin and it runs out.
• On the CSV splitter, getTools() returned exactly one tool: splitLargeCsv, with the description we wrote in the markup.
• On the delimiter converter it returned fixCsvDelimiter, and on the JSON and CSV converter it returned convertJsonCsv. One tool per page, matching the markup.
• On two pages that explain a workflow without containing a tool, getTools() returned zero tools. No declaration, nothing exposed.
• navigator.modelContext.executeTool existed on the page, so an agent could in principle call the tool it had discovered.

The empty parameter column is the finding, not a formatting quirk. For convertJsonCsv the returned schema was {"type":"object","properties":{},"required":[]} while the page contains a labelled file input. The tool is discoverable and described, but there is no typed field for the file, so an agent can see the capability and cannot supply the input. If your product depends on an agent handing you a file, that is the gap to plan around, and it is the reason we also publish a plain-file description of what the site does rather than relying on the trial alone.

What is the difference between WebMCP and MCP?

They are not competitors, and Chrome's comparison page says so directly: WebMCP is not an extension or a replacement of the Model Context Protocol. The same page draws the line by where the functionality lives. MCP connects an agent to external systems, data sources and workflows, works on any platform, commonly speaks JSON-RPC and is implemented through language SDKs. WebMCP is a frontend browser standard whose two APIs interact only with the browser's own agent, and it leaves out server-side concepts such as resources ( WebMCP versus MCP).

Do you need WebMCP if you already have llms.txt?

They answer different questions. A file such as llms.txt describes your content so an assistant can read the right pages; WebMCP declares your actions so an agent can perform one. Publishing the file is available to everyone today, needs no enrollment and no browser support, and it is the part that already shows up in audits. WebMCP is the part that will matter when browser agents are common, and the markup cost of adding it to a form you already have is two attributes.

What should a site owner do about it this month?

Three things, in this order, and none of them require committing to the trial.

1. Inventory the forms that do real work. A form that submits a quote request or runs a converter is a candidate. A newsletter box is not, because the agent gains nothing. Write down what each one produces.
2. Annotate one form and check what an agent sees. Add toolname and tooldescription, put toolparamdescription on the fields whose purpose is not obvious from a label, and confirm each field shows up as a typed parameter. This is where our own test caught an empty schema.
3. Describe the site in plain files regardless. Join the origin trial if you want the API, and publish llms.txt plus a machine-readable tool list anyway, because those work in clients that will never implement an origin trial.

One honest caveat to close on. WebMCP is described as an early preview, the token expires, and the field annotations omit at least file inputs today. Anyone selling you a guaranteed outcome from it is selling something the specification does not yet deliver. What you can verify is narrow and real: whether your page declares a tool, and whether a browser reads it back. Our pages do, and we showed the output above.

Frequently asked questions

I build this layer for other sites: llms.txt, agent-tools.json and WebMCP declarations, verified against the live pages. Details at /agent-ready.