WebMCP lets AI agents use your website as a tool. Should you ship it yet?

For two years the plan for AI agents using websites has been to let them look at the screen and click like a person. WebMCP proposes the opposite: your site hands the agent a list of the things it can actually do, with the exact parameters each one needs. It is in a Chrome origin trial right now, the API has already been renamed once, and most businesses should not build on it this quarter. Here is how to tell whether you are one of the exceptions.

What WebMCP actually is

WebMCP stands for Web Model Context Protocol. It adds an object to the page — document.modelContext — through which your JavaScript registers tools that an AI agent running in or through the browser can invoke. A registered tool looks almost exactly like a function definition you would send to a model API: a name, a description the model reads to decide when to use it, an inputSchema describing the arguments, and an execute handler that does the work on your page.

document.modelContext.registerTool({
  name: "check_availability",
  description: "Check available appointment slots for a service on a date",
  inputSchema: {
    type: "object",
    properties: {
      service: { type: "string" },
      date:    { type: "string", format: "date" }
    },
    required: ["service", "date"]
  },
  async execute({ service, date }) {
    const slots = await getSlots(service, date);   // your existing code
    return { content: [{ type: "text", text: JSON.stringify(slots) }] };
  }
});

There is also a declarative path, where HTML attributes on an existing form expose it as a tool without writing a handler at all. That matters more than it sounds: for a large share of business sites, the meaningful actions already are forms, and the declarative route turns an existing booking or enquiry form into an agent-callable tool with markup rather than a rewrite.

The registration call is strict about the things that break models. registerTool() throws an InvalidStateError if a tool with that name already exists, if the input schema is invalid, or if the name or description is an empty string. An empty description is treated as a fault rather than a warning, which tells you how the design views descriptions: they are the interface, not documentation.

Why "give agents tools" beats "let agents click"

The current generation of browser agents works by reading a rendered page, guessing which element corresponds to the user's intent, clicking it, and re-reading the result. That approach has three failure modes that no amount of model capability removes: it breaks when you change your markup, it is slow because every step costs a screenshot and a model call, and it cannot see anything the interface does not display.

A tool call removes all three. The agent does not care where the button is. The parameters are typed, so a date is a date rather than whatever the agent typed into a text field. And your handler can return structured data the page never renders, such as the full availability set rather than the first ten slots.

The part most site owners miss is the security asymmetry. A WebMCP tool runs inside the page, in the user's own browser session, so it inherits the login the user already has. There is no API key to issue, no OAuth flow to build, and no way for someone who is not on the page to call it. That is a genuinely different proposition from publishing an API or running a conventional MCP server, and it is the reason the standard exists at all.

WebMCP vs the other ways of being "AI ready"

Four different things get sold under the same heading, and they do not substitute for each other. This is the comparison that should decide your budget.

Note the third column. WebMCP does nothing for whether ChatGPT or AI Overviews cite you. It changes what happens after an agent arrives. Anyone pitching WebMCP as an AI SEO tactic is selling the wrong thing, and the confusion is worth naming early because it is already in circulation.

The status, honestly stated

This is a specification in motion, and the dates matter more than the enthusiasm.

A specification that renamed its entry point one version into its own origin trial is not one to hard-code against. The practical implication is architectural rather than cautionary: put the tool registration behind a feature check and a thin adapter, so a rename costs you one file rather than a sprint.

Should you build it? A decision matrix

The honest answer for most HyberX clients this quarter is no, and the ones for whom it is yes share a specific shape. The test is not your industry, it is whether a visitor's goal is a parameterised transaction: something with inputs, options and a result, that is tedious to complete by clicking.

The three tools to expose first

Teams that pilot this tend to over-register: twenty tools, half of them trivial. A model choosing between twenty similar descriptions performs worse than one choosing between three distinct ones. Start with the smallest set that covers a real session.

1. A lookup tool. search_catalogue, check_availability, find_order. Read-only, no side effects, cheap to get right, and it is what an agent needs before it can do anything else. This is where almost all the value is in the first month.
2. A quote or configuration tool. Inputs the user would otherwise enter across three screens, returning a structured result. Read-only again, so a bad call costs nothing.
3. One consequential tool. book_appointment, add_to_cart, submit_enquiry. Exactly one, marked as consequential so the browser or agent asks the user to confirm before it runs. Resist adding "cancel" or "delete" tools in a pilot; the upside is small and the failure mode is a customer whose booking vanished.

Write the descriptions as if for a new employee with no context and no ability to ask a follow-up question. "Check available appointment slots for a service on a date, in the clinic's local timezone; returns an empty list if the clinic is closed" is a better description than "checks availability", and description quality determines whether the tool is chosen correctly far more than your schema does.

The security work is not optional

Handing an agent callable tools changes your threat model, and the research literature moved faster than the specification did. Two risks deserve naming.

Injected instructions. A model processes instructions and data as the same stream of tokens, so any untrusted text an agent reads on your page — a product review, a support thread, a third-party widget's output — can attempt to redirect it. Researchers have also described mid-session tool injection, where a third-party script registers malicious tools during a live session. The defences are to treat retrieved text explicitly as data rather than instructions, and to audit what your third-party scripts can do on pages that register tools. If a chat or review widget can inject script, it can inject tools.

Irreversible actions. The specification provides a consequential hint precisely so high-stakes or non-reversible tools can trigger a human confirmation before they execute. Use it, and then assume it is advisory. The rule that actually protects you is older and duller: enforce every authorisation and business rule on the server. A tool handler is client-side code. Treat a tool call exactly as you would treat a request forged by a hostile user, because in the injection case that is what it is.

This is also the point where WebMCP intersects with the agentic checkout changes already live in payments. If an agent can both find the product and complete a purchase, the confirmation boundary is the only thing standing between an automated session and a chargeback.

What it does to your analytics

One consequence gets discovered late, usually by someone looking at a conversion report. An agent-driven session that completes through tool calls does not generate the page views, scroll depth or click events your funnel is built on. If tool usage grows and you have not instrumented it, your data will show conversions rising while engagement collapses, and someone will spend a month optimising a funnel that a growing share of users never touch.

Fix it at build time: fire a distinct event on every tool invocation, with the tool name as a parameter, and segment agent-assisted sessions separately from human ones. Both numbers are useful. Averaged together, neither is.

What this means if you are commissioning web work

Two questions are worth asking any agency or developer quoting on "AI agent readiness" right now. First: does the proposal distinguish between citation work and action work? Those are separate budgets with separate outcomes, and conflating them is the single most common way this gets oversold. Second: what happens to the deliverable if the API is renamed again or the origin trial ends without shipping? If the answer is not "we swap one adapter", the architecture is wrong.

For most businesses the highest-return preparation for the agentic web remains unglamorous and fully within today's standards: semantic HTML, forms that work without JavaScript, server-side validation, honest structured data and fast pages. Every one of those improves agent outcomes today, improves human conversion today, and cannot be deprecated by a Chrome release. WebMCP sits on top of that foundation. It is not a substitute for it.

Frequently asked questions

What is WebMCP?

WebMCP is a proposed web standard that lets a website register named tools an AI agent can call directly, instead of the agent reading the page and guessing where to click. A tool has a name, a description, an input schema and a function that runs on the page. It is incubating in the W3C Web Machine Learning Community Group with editors from Google and Microsoft, and is available in Chrome as an origin trial rather than as a shipped feature.

Is WebMCP available in Chrome right now?

Only through an origin trial. The trial opened in Chrome 149 and is scheduled to run through Chrome 156, which means a site must register for a trial token to expose tools to Chrome users. The API surface has already moved once, from navigator.modelContext to document.modelContext, with the navigator form deprecated in Chrome 150 while the trial continues to ship it.

Is WebMCP the same as an MCP server?

No. A conventional MCP server runs on your infrastructure and exposes tools to any client that connects with credentials. WebMCP runs inside the page in the user's own browser, so the tools inherit the session the user is already logged into and cannot be called by anyone who is not on the page. A server gives you reach; WebMCP gives you the user's existing session and no separate authentication layer to build.

Does WebMCP help my site show up in ChatGPT or AI Overviews?

No. WebMCP is about what an agent can do once it is on your page, not about whether an answer engine cites you. Citation and retrieval are driven by crawlable content, structured data and links. Treat WebMCP as conversion infrastructure for agent-driven sessions, not as an AI SEO tactic, and do not let a vendor sell it as one.

Which businesses should implement WebMCP first?

Sites where a visitor's goal is a parameterised transaction that is tedious to complete by clicking: booking, availability checks, multi-filter catalogue search, quoting, account or order lookup and reordering. Brochure sites, single-service local businesses and content publishers gain little, because there is no multi-step task for an agent to shorten. Travel, retail and financial platforms including Expedia, Booking.com, Shopify, Etsy, Instacart, Target, Redfin, Credit Karma and TurboTax have been named by Google as early experimenters, which is a fair description of the shape of site that benefits.

What are the security risks of exposing WebMCP tools?

Two matter most. First, an agent acting on your page can be steered by injected instructions in any untrusted text it reads, including third-party content and script-injected tool definitions, a class of attack researchers have described as mid-session tool injection. Second, a tool that performs an irreversible action can be called without the user reading a confirmation screen. The mitigations are to mark consequential tools so the browser or agent asks for human confirmation, to enforce every permission check server-side rather than in the tool handler, and to treat retrieved text as data rather than instructions.

The takeaway

WebMCP is the most credible attempt yet at letting agents use websites properly, and it is still a draft inside a time-boxed trial with an API that was renamed one version in. Those two facts are not in tension; they describe exactly where it is. If your site's value is a parameterised transaction, spend a week on a lookup tool, a quote tool and one confirmed action, behind a feature check. If it is not, spend that week on forms that work, markup that means something and pages that load fast — then revisit when the trial either ships or lapses. The businesses that get this wrong will not be the ones who waited. They will be the ones who bought an "AI readiness" package that confused being cited with being useful.