WebMCP: what the spec actually says, and what we actually shipped

What WebMCP actually changes

A website today speaks to two audiences: humans, and robots that read. For the latter the work is well understood — structured markup, clean content, context files. The agent reads, interprets, summarises, and sometimes gets it wrong. WebMCP introduces a third audience: agents that no longer interpret, they call. The site declares typed functions, the agent executes them and receives a structured answer. The difference is not cosmetic. When an agent reads a pricing page, it produces a paraphrase whose accuracy nobody controls. When it calls a function, it gets the exact value, with its source.

• Reading: the agent guesses from your text, and the margin of error is yours to carry.
• Calling: the agent receives the value you compute, with the origin that produced it.
• The API is purely additive — a browser that does not know it renders the site identically.

Three errors you will read everywhere

The specification moves fast: roughly one breaking change per quarter since 2025. The consequence is that most guides published in 2026 are already wrong on at least one structural point. We collected the three most frequent by reading the specification and the Chrome documentation directly, rather than copying other articles.

The lifecycle, in one snapshot

Registration fits in a single call. What matters is not its length but what it implies: tools are attached to the document, not the site. They vanish on every navigation and must be registered again. Unregistering no longer goes through a dedicated method — unregisterTool was removed in April 2026 in favour of an abort signal, a month after provideContext was dropped.

• One registerTool call per tool: batch registration no longer exists.
• A shared AbortController whose abort unregisters everything on unmount.
• The browser does not validate inputs against your schema: validation lives in your code.
• Descriptions have budgets: 30 characters for a name, 500 for a description, 1,500 for an output.

What we expose, and why these four

We picked four functions sharing three properties: they compute, they modify nothing, and they rest on data we already publish. None touches personal data, none triggers an action. This is the safest profile a site can expose, and it matches exactly what the specification recommends annotating as read-only.

• benchmark-cpl-maroc — median cost per lead, per thousand impressions, per click and return on ad spend for a sector.
• simuler-budget-google-ads — expected clicks, conversions and cost per acquisition for a monthly budget.
• comparer-seo-google-ads — the cost of the same traffic bought or built, with the break-even point.
• calculer-roi-leads — projected leads, customers and revenue from a traffic volume and conversion rate.

The rule we set ourselves: never two truths

The main risk of a WebMCP implementation is not technical, it is editorial. If the tool exposed to the agent and the visible interface do not share the same computation, they will diverge one day — and you will have two contradictory official numbers on the same site, one shown to your visitors, the other recited by an assistant. So we extracted the computations into a single module, consumed by both the interface and the tools. Divergence is not monitored: it is made impossible by construction.

• A single implementation of the computation, shared between screen and agent.
• All the unstable API surface isolated in one facade, so the next spec change touches one file.
• Values displayed after the refactor were compared to those before: identical.

The trap that would have made it all inert

The origin trial token travels in a meta tag in the HTML. So we put it in a build environment variable — and that is precisely where the setup fails silently for most people who attempt it. Our continuous integration builds the site without injecting variables: the token present locally would have vanished in production, with no error message, no broken build, nothing observable. The feature would simply have been absent. Since an origin trial token is public by nature — it is served to every visitor — we versioned it with the code, documenting its expiry date.

• Always check the tag is present in the HTML served in production, not only locally.
• An origin trial token is not a secret: treating it as one creates the bug rather than preventing it.
• Write the expiry date down somewhere: ours falls on 17 November 2026.

Should you ship it now?

Let us be clear about the return. No consumer agent calls WebMCP tools today: neither conversational assistants nor generative search engines. Industry consensus places real usage twelve to eighteen months out. Shipping today brings no traffic, no ranking, no leads. What it brings is different and measured differently: first-hand knowledge of an interface your competitors will discover later, and the position of the one who already solved the problems others will hit. If your trade is technical, that argument is enough. If it is elsewhere, wait.

• No short-term traffic or ranking gain: claiming otherwise would be dishonest.
• The specification remains a draft off the standards track — it may still change or be abandoned.
• Entry cost is low if your functions already exist; high if you must invent them for the occasion.