Contents

Six chapters plus an executive summary and a forward view, written for the operator who has to make a build decision this quarter. Every exhibit states its takeaway in the title and cites its source. Where a number is reported by a vendor rather than independently audited, we say so on the chart, not in a footnote you will never read.

Agents stopped reading your site. They started calling it.

For two years we have told clients the same thing: stop optimizing for Google, start optimizing to become the answer. That is still true. But a new layer is forming underneath the answer, and most teams cannot see it yet. The agent has stopped reading your page to the user. It has started doing the task on the page itself.

Here is what most teams have not internalized. Being named in an AI answer gets you into the consideration set. That is the game we have spent two years helping clients win, and it still matters. But the moment the agent stops recommending and starts doing, booking the demo, pulling live pricing, starting the trial, completing the checkout, a citation is no longer enough. The agent has to be able to call your site. If it cannot, you are quietly routed around, no matter how good your content is.

That is what WebMCP is. Not developer trivia, not a standards-body footnote. It is the layer that turns your website into typed, callable tools an agent can invoke without screenshotting your pages and guessing at pixels. A site that exposes none of this is, to an agent in 2026, exactly what a business with no website was in the year 2000: technically real, functionally invisible.

So we now think about discoverability in three layers, and they stack. Visibility is whether the agent can find you. Citability is whether it trusts you enough to say your name. Callability is whether it can actually invoke you and finish the job. Most of the market is still fighting for visibility. A smaller group has figured out citability. Almost no one is building for callability yet. In the top 200,000 domains on the internet, the number we found shipping WebMCP in production was zero. That gap is the opportunity, and it is the reason we wrote this report.

One more thing, because it changes how you should read what follows. This is an early market. WebMCP is a W3C Community Group draft, not a finished standard. It runs behind a Chrome origin trial, not in a stable browser everyone has. Some of the most quoted performance numbers come from the same organizations building the protocol, and we flag every one of those rather than dressing them up as audited fact. We would rather you trust this report than be impressed by it. But the direction is not ambiguous, and the compounding dynamics that made early SEO moats so durable are already visible. The only real question is whether you move before your competitors do, or after.

The agent-ready web has a published standard and almost no one building on it

WebMCP moved from two independent prototypes to a W3C Community Group draft and a Chrome origin trial inside fifteen months. The specification exists. The browser support is shipping. What is missing is you, and almost everyone like you. That asymmetry, a real standard with near-zero production adoption, is the most actionable fact in this report.

Five shifts every product and engineering leader must internalize

Your site stops being a picture to interpret and becomes an API to call

The Model Context Protocol (MCP) gave AI agents a standard way to call tools on a server. WebMCP takes that same idea and moves it into the browser. A page running in the user's tab declares its tools through a single browser API, and any agent in that browser, an extension, an agentic browser, an assistant, can discover and invoke them.

The shift, side by side

The same task, "find a product and add it to the cart," done two ways. The difference is not cosmetic. It is the difference between an agent that works on your site and one that gives up on it.

A tool is a name, a description, a typed input, and a promise

When an agent asks your page what it can do, it gets back a list of structured tool definitions. Each one is small, self-describing, and machine-checkable. Here is a single tool exactly as an agent receives it.

{
  "name": "searchProducts",
  "description": "Search the product catalog by keyword and
                  return matching items with price and stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Search keywords, e.g. 'wireless headphones'"
      }
    },
    "required": ["query"]
  },
  "annotations": { "readOnlyHint": true }   // safe to call without asking
}

Where WebMCP sits: browser-side, not server-side

MCP and WebMCP are siblings, not competitors. The original protocol connects agents to back-end systems. WebMCP connects agents to the live page in front of the user. The distinction decides which one you reach for.

The three layers of agent discoverability

This is the mental model we use with every client. The layers stack, and they are won in order. WebMCP is the engine of the third layer, the one almost no one has reached.

Agents are crawling the web at scale, and giving almost nothing back

The agentic web is not a forecast. It is current traffic. AI bots now make up a large and concentrated slice of all automated requests, and the relationship is lopsided: they take far more than they return. That imbalance is exactly why a structured, efficient action layer matters now.

The web tells agents what they may do, and almost never what they can do

There is a vast difference between a passive permission signal and an active capability. The first says "you are allowed to look." The second says "here is the function, call it." Sites have adopted the first almost universally and the second almost not at all. That is the cliff, and it is where the opportunity lives.

Why now: the ecosystem caught up in a single season

WebMCP stopped being a research curiosity in the first half of 2026. Four milestones, inside four months, turned it into something you can build on today.

A page publishes a menu of actions, and the agent calls one by name

There is no scraping in this model, and no guessing at the DOM. The page tells the agent exactly what it can do and what each action needs. The agent supplies intent and arguments. Your own code does the work. The whole exchange is four steps, and it runs in the tab the user already has open.

Three properties that make this different from an API or a scraper

There are two ways to declare a tool, and you can start with the one you already know

The specification offers two front doors to the same capability layer. The declarative path turns an existing form into a tool with a few HTML attributes. The imperative path registers a tool in JavaScript with a typed schema and a handler. Same result, different effort, different control. Toggle between them below.

<!-- An ordinary search form, marked up as a callable tool -->
<form id="search"
      toolname="searchProducts"
      tooldescription="Search the catalog and return matching products">

  <input name="query" type="text" required
         tooldescription="What to search for, e.g. running shoes">

  <input name="maxPrice" type="number"
         tooldescription="Optional price ceiling in USD">

  <button>Search</button>
</form>

navigator.modelContext.registerTool({
  name: "searchProducts",
  description: "Search the catalog and return matching products",
  inputSchema: {
    type: "object",
    properties: {
      query:    { type: "string", description: "What to search for" },
      maxPrice: { type: "number", description: "Price ceiling, USD" }
    },
    required: ["query"]
  },
  readOnlyHint: true,          // declares this call changes nothing
  async execute({ query, maxPrice }) {
    const hits = await store.search(query, { maxPrice });
    return { content: hits.map(r => ({ name: r.title, price: r.price })) };
  }
});

One typed call replaces a screenful of guesswork

When an agent acts through the screen, it spends most of its budget reading: capturing pixels or markup, reasoning about what is where, then hoping the click lands. A WebMCP call skips all of that. It sends arguments to a function and gets structured data back. The cost difference is not marginal. It is an order of magnitude.

The transport and the trust boundary, in five facts

Expose the actions that already drive your business, starting with the safe ones

You do not need a tool for everything. You need a tool for the handful of actions that already convert, and you should ship the read-only ones first. They carry no consent friction, so they go live fast and start earning agent trust while you build toward the transactional ones.

Three rules for choosing your first tools

Five levels from readable to trusted, and most sites are still on level zero

Agent-readiness is a ladder, not a switch. Each level is shippable on its own and earns value before you climb to the next. Click a level to see exactly what it takes. The gap that matters, the one almost no one has crossed, sits between level one and level two.

Your tool description is read by a model, not a person, so write it that way

When an agent decides whether to call your tool, it reads one thing: the description string. Not your brand, not your design, not your rank on a results page. That sentence is the entire pitch, and it is graded by a model choosing between options. Most teams write it like a label. The ones who write it like an instruction get called.

"Search our site"

"Search the product catalog by
keyword. Returns up to 20 items
with title, price in USD, and
stock status. Use when the user
wants to find or compare products."

The four parts of a description that gets called

A callable site is a powerful site, and power is what attackers aim at

Every risk below shares one root cause: an agent cannot reliably tell an instruction from data, so the page has to enforce the boundary the model will not. Expand each to see the failure and the control that contains it. None of these is a reason to wait. They are the reasons to ship carefully.

Read freely, confirm before you write, and never surprise the user

Consent is not one dialog box bolted onto everything. It is a gradient that should match the stakes of the action. Get it right and it is invisible where it should be and reassuring where it matters. Get it wrong and you either train users to click through warnings or you smother safe actions in friction.

What good confirmation actually looks like

The site an agent trusts is the site an agent returns to

It is tempting to read this chapter as a list of costs: confirmations to design, tools to scope, logs to keep. That framing is backwards. In a market where almost no one is callable yet, the safety work is not overhead. It is how you become the default, and the default is the most durable position on the agentic web.

Three horizons: prove it in thirty days, scale it in ninety, own it in a year

This is not a transformation program. It is a sequence of small, shippable bets, each one earning the right to the next. The plan is deliberately front-loaded toward proof, because the hardest and most valuable step is the first one: an agent calling your tool and getting a clean result.

What to do in the first month, who owns it, and how you know it worked

Phase one fits in four weeks and on one page. It needs a front-end engineer, a marketer who can write, and someone who watches the numbers. No new infrastructure, no procurement cycle, no platform migration. Here is the week-by-week.

The five metrics that tell you it is working

This is an asymmetric bet: cheap to make, expensive to miss

Strip away the detail and the decision is simple. Moving now costs one tool and a few well-written descriptions, and the downside is small and reversible. Waiting costs nothing you can see, until a competitor becomes the action an agent takes by default and the slot is no longer yours to win. The two sides of this bet are not symmetric.

Where this goes next, with our confidence stated plainly

Forecasting a young standard is an exercise in humility. The direction is clear; the timing is not. Below are the calls we are willing to make, each tagged with how sure we are. Treat the high-confidence rows as planning assumptions and the low-confidence ones as scenarios to watch, not bets to size.

One next step, decided by who you are

A report earns its keep only if it changes what you do on Monday. So here is the single highest-leverage move for each person likely to be reading this, and the reason that move belongs to you specifically and not to the department down the hall.

How we gathered this, what we could not verify, and where our interests lie

Three things you are owed before you act on anything in these pages: how the evidence was assembled, where it is thin, and what we stand to gain if you believe us. We have tried to be straight about all three.

Every external number in this report, traceable to where it came from

This is the full accounting. Hard counts from neutral sources are marked as such. Vendor-reported figures are labeled so you can weight them. Anything attributed to MaximusLabs is our own analysis, not external data dressed up as fact.