Are You Ready for WebMCP? What It Takes to Make Your Site Agent-Ready

Bots now generate more web traffic than people do. On June 3, 2026, Cloudflare published Radar data showing automated requests at roughly 57.5 percent of HTML web traffic against 42.5 percent from humans, a crossover the company had expected more than a year later (Forbes).

The ratio itself is not the interesting part for platform teams. The interesting part is that a growing share of that traffic is an agent trying to finish a real task for a real customer, and your site is making it guess. WebMCP is the standard that removes the guessing. I covered the mechanics of the API in What is WebMCP?. This post is about the question I get asked immediately after that one: are we ready, and what would it take?

Where the standard actually stands today

WebMCP is a proposed web standard developed through the W3C Web Machine Learning Community Group, with the explainer on GitHub and an origin trial in Chrome starting with Chrome 149. Locally, you can enable it behind a flag at chrome://flags/#enable-webmcp-testing.

That is the honest scope. One browser engine, an origin trial, and a spec that is explicitly under active discussion. The API surface has already moved: the canonical entry point is now document.modelContext, and Chrome's earlier navigator.modelContext form is on its way out. Registration changed shape too, from a call that replaced the entire tool list to one that adds a single tool at a time with an AbortSignal for cleanup.

When we architect for a moving target, the discipline is straightforward. Do not build around the surface that keeps moving. Build the layer underneath it, which is not going to move, and keep the binding to the browser API thin enough to rewrite in an afternoon.

Most of the readiness work is not WebMCP at all

Tool registration is about ten lines of JavaScript. Every team I have worked with underestimates readiness because they look at those ten lines and conclude the work is trivial.

The work is not registration. The work is having functions worth registering. Three preconditions have to be true before the API is even relevant:

• Your site performs jobs, not just page views. Booking, filtering, quoting, submitting, checking status.
• Those jobs can be invoked without walking the DOM. If completing a task requires clicking through four components in order, you have a UI flow, not a callable capability.
• Each job returns a result you can serialize into a string a model can read and act on.

If any of those is false, WebMCP will not help you. This is the same architectural discipline that separates a service layer from its presentation layer, and most enterprise sites have never had to enforce it, because the only consumer was a browser rendering pixels for a person.

A readiness audit you can run this month

Here is the checklist we walk clients through. It works as a half-day exercise with an architect and a lead front-end engineer in the room.

Inventory the jobs, not the pages. Write down every outcome a customer comes to your site to achieve. Aim for verbs. A twelve-page product configurator is one job, not twelve. Most enterprise sites land somewhere between six and twenty genuine jobs, which is a far smaller surface than the sitemap suggests and a much more useful roadmap.

Check whether your forms can describe themselves. The declarative API turns a standard HTML form into a tool with two attributes, toolname and tooldescription, and treats the fields as parameters. When you skip the optional toolparamdescription attribute, the browser falls back to the associated label, and then to aria-description. That means your label hygiene becomes your tool schema quality. Teams that invested in accessibility get paid for it twice here.

Separate business logic from click handlers. The imperative API registers a plain JavaScript function with a JSON Schema for its inputs. If your search logic lives inside an onClick closure that reads three pieces of component state, you cannot register it without refactoring. Pull the logic into a function that takes arguments and returns a value, then let both the button and the tool call it.

Verify origin isolation. WebMCP is only available in origin-isolated documents. If a document enables document.domain, for example by sending the Origin-Agent-Cluster: ?0 header, the WebMCP APIs are disabled entirely. This is a real blocker for older enterprise portals stitched together across subdomains, and it is the kind of thing you want to discover during an audit rather than during a sprint.

Map your cross-origin iframes. Both APIs are gated by the tools permissions policy, which defaults to self. Tool registration is off by default inside cross-origin iframes unless the parent delegates with allow="tools". If your checkout, scheduler, or support widget is a third-party embed, that vendor's readiness is now part of your readiness.

Classify every action by consequence. Tool registration accepts annotations that tell the agent and the browser how to treat a call. readOnlyHint marks a lookup with no side effects. consequentialHint marks something significant or irreversible, which lets browsers enforce a confirmation step before it runs. untrustedContentHint marks output containing user-generated content or external data, signaling that the payload needs sanitizing to limit indirect prompt injection. Getting these wrong is the most likely way a WebMCP rollout hurts you.

Decide your submission model. With the declarative API, the default is that the agent fills the form and the human clicks submit. Adding toolautosubmit lets the model trigger submission directly. The SubmitEvent interface carries an agentInvoked boolean so you can branch on agent-initiated submissions, and a respondWith() method so you can hand the model a real result instead of a page navigation. Choose deliberately, per form, and default to the human click on anything that moves money.

Here is what a declarative tool looks like in practice:

<form toolname="check_order_status"
      tooldescription="Look up the status of a customer order by order number."
      action="/orders/lookup">
  <label for="orderNumber">Order number</label>
  <input type="text" name="orderNumber" id="orderNumber" required>

  <select name="detail"
          toolparamdescription="How much detail to return about the order.">
    <option value="summary">Status only</option>
    <option value="full">Full history including shipping events</option>
  </select>

  <button type="submit">Check status</button>
</form>

And the imperative equivalent, with feature detection and consequence annotations:

// Feature detect. The API is origin-trial only, so never assume it exists.
if ('modelContext' in document) {
  await document.modelContext.registerTool({
    name: 'search_inventory',
    description:
      'Search available inventory by keyword and location. Returns matching ' +
      'items with SKU, price, and quantity on hand.',
    inputSchema: {
      type: 'object',
      properties: {
        query: { type: 'string', description: 'Keyword or product name' },
        location: { type: 'string', description: 'Store or warehouse code' },
      },
      required: ['query'],
    },
    annotations: {
      readOnlyHint: true,
      consequentialHint: false,
      untrustedContentHint: true,
    },
    execute: async ({ query, location }) => {
      const results = await searchInventory({ query, location });
      return JSON.stringify(results);
    },
  });
}

Note that searchInventory is the same function the search box calls. That is the whole point. If you find yourself writing agent-only logic, stop and refactor, because you have just created a second code path that will drift.

What WebMCP does and does not do for AEO and GEO

This is where I have to be direct, because the marketing around agent readiness has gotten ahead of the specification.

WebMCP is not a discoverability mechanism. Chrome's own documentation lists tool discoverability as a current limitation: clients and browsers have to visit your site directly to learn that it has callable tools. There is no registry, no crawler signal, and nothing in the standard that puts you into an AI-generated answer. If a vendor tells you that adding WebMCP tools will improve your citation rate in ChatGPT or Google's AI results, ask them for the mechanism, because as of today there is not one.

So keep the two jobs separate in your planning.

Getting named is still answer engine and generative engine optimization work. Structured, retrievable, well-modeled content is what gets summarized and cited. That is the discipline we cover in AEO: The New Marketing Imperative and What Is Generative Engine Optimization, and the competitive picture keeps shifting as the assistants diverge from Google's rulebook, which is worth reading alongside this piece on where GEO guidance breaks down.

Getting the job done is WebMCP work. It governs the ninety seconds after an agent arrives, which is the part AEO and GEO have never touched. An agent that finds you through an AI answer and then fails to complete a booking because it misread your date picker is a visibility win and a business loss.

The two disciplines converge on one thing, which is why I keep pushing clients toward it: both are downstream of your content model. An answer engine cannot extract a fact that lives inside a rich text blob, and you cannot expose a reliable tool over data you cannot address by field. Structured content is the shared substrate, and it is the investment that pays regardless of which standard wins. That argument is the same one behind what agentic CMS actually means once you strip the marketing off it.

There is one genuinely new thing WebMCP gives your marketing team, and it is measurement. The declarative API fires a toolactivated event on the window when an agent invokes a tool, and a toolcancel event when the operation is cancelled or reset. That is a telemetry stream you have never had. For the first time you can measure agent task completion instead of inferring it from strange session patterns in your analytics. In my view that is the strongest near-term reason to join the origin trial, ahead of the feature itself. You learn what agents are trying to do on your site while the cost of learning is still low.

How to sequence this over two quarters

1. Run the readiness audit. Job inventory, origin isolation check, iframe map, form label review. No code changes.
2. Fix the substrate. Refactor the top three jobs into callable functions with real return values, and clean up the labels and content model they depend on. This work has value even if WebMCP never ships.
3. Instrument one flow behind the origin trial. Pick a read-only job, something like status lookup or inventory search, where a wrong answer costs nothing. Register the token, ship it, watch the events.
4. Add consequential tools only after you trust the confirmation path. Anything that charges a card, books a resource, or writes to a system of record waits until step three has produced data.
5. Review at the next Chrome milestone. The spec is moving. Plan on a quarterly review of the binding layer rather than a one-time implementation.

Where we can help

We do three things on this in client engagements. We run the readiness audit and hand you the findings whether or not you work with us further. We do the substrate work, which is usually content modeling and a service-layer refactor rather than anything agent-specific. And we build and instrument the first tools so your team has a working pattern to extend, including the measurement layer that turns agent activity into something your marketing team can actually report on.

If you want a starting point that costs nothing, run the job inventory yourself. Six to twenty verbs on a whiteboard will tell you more about your agent readiness than any vendor assessment.

Key takeaways

• WebMCP is real but early. One browser engine, an origin trial, and an API surface that has already changed twice. Keep your binding layer thin.
• The readiness work is architectural, not API-specific. Callable functions, clean labels, origin isolation, and a content model with addressable fields.
• WebMCP will not improve your AEO or GEO visibility. It has no discovery mechanism. It determines what happens after the agent arrives, which is a different and equally important problem.