We Exposed Our Tool to AI Agents With WebMCP: An Implementation Report

Most of the writing about WebMCP right now is speculation about what it might mean. We decided to find out by shipping it. This is what actually happened when we exposed one of our own tools to AI agents, including the parts the documentation doesn’t tell you and the design problem nobody seems to be discussing.

Fair warning up front: WebMCP is a browser standard in origin trial, not a finished feature. Nothing here is a performance claim. It is an implementation report.

What is WebMCP, in practical terms?

WebMCP lets a web page declare structured tools that an AI agent can discover and call directly, instead of the agent trying to drive your interface by guessing which buttons to click. The page effectively acts like an MCP server with client-side logic, and the browser handles discovery, permissions and execution.

It came out of the W3C Web Machine Learning Community Group, with engineers from Google and Microsoft involved. It shipped in Chrome behind a flag and moved into an origin trial during 2026. Sources disagree on the exact trial windows and which Chrome versions are covered, so treat any specific version number you read — including ours — as approximate.

The distinction that matters for anyone thinking about AI visibility: schema and llms.txt make a site readable by machines. WebMCP makes it operable. Those are different problems, and the second one is new.

What did we actually build?

We exposed our AI Citability Scorer as a callable tool. An agent can hand it a URL or a block of draft text and get back a citability score, a breakdown across seven structural signals, and a prioritised list of fixes — the same output a person gets from the interface.

We picked that tool deliberately. It’s read-only, it produces a self-contained result that’s genuinely useful inside a conversation, and it doesn’t change anything on our side. If you’re choosing a first tool to expose, those three properties are a good filter.

What the documentation doesn’t tell you

Four things cost us time, and all four are things you’d only hit by building it:

• The API is on document, not navigator. Registration is document.modelContext.registerTool(). A lot of the secondary write-ups say navigator.modelContext, which is wrong and will fail silently in the worst way — your feature detection simply returns false and you conclude the browser doesn’t support it.
• Feature detection is not documented. There is no stated canonical check, so we test for the object and the method together before touching anything.
• The return shape is not specified. Chrome’s documentation does not say whether execute must return a content array, a structured object, or a plain string. Its own samples return plain strings, so that’s what we do. This may well firm up later.
• The permissions policy defaults to self. The tools policy allows same-origin by default, so a same-origin implementation needs no header changes at all. We had budgeted time for server configuration that turned out to be unnecessary.

The registration itself is unremarkable once you know the shape. You provide a name, a description, a JSON Schema for the input, an async execute function, and optional annotations — readOnlyHint, untrustedContentHint, consequentialHint. Unregistering works by passing an AbortSignal in the options.

One note on annotations that is easy to skip: we set untrustedContentHint because the text being scored comes from an arbitrary third-party page. If your tool ingests content the user did not write, that hint is the honest setting.

The problem nobody is discussing: agents don’t get tired

Here’s the part we think matters most, and we have not seen it raised anywhere.

Our scorer costs real money per run — it makes a model API call. In the interface, that’s bounded by human behaviour and by an email gate that allows one free run. An agent has neither constraint. An agent can call a tool in a loop, and it will do so without malice, simply because retrying is a reasonable strategy when something looks incomplete.

If we had exposed the tool without thinking about this, we would have published an unauthenticated, uncapped endpoint to our own paid API budget and called it innovation.

So the tool enforces the same entitlement the interface does. While a free run hasn’t been claimed, calling the tool returns an explanation and a pointer to the page, rather than silently running. Once a person unlocks it, the agent inherits that entitlement in the same session.

The general rule we’d draw from this: before exposing a tool, ask what happens if it’s called four hundred times in a minute by something with no concept of cost. If the honest answer is “we would notice on the invoice”, the tool is not ready. This applies to anything that writes data, sends a message, or bills per call.

How do you test this without native support?

Most people cannot run the origin trial, which makes testing awkward. Our approach was to stop waiting for the browser.

We injected a mock document.modelContext with a registerTool that simply captures what it’s given, then re-ran our module so registration happened against the mock. That let us assert the exact schema and annotations the agent would see, and then call execute() directly with test inputs.

We checked four paths: no input supplied, the entitlement refusal, a cancelled request, and the full scoring run. Testing the real scoring path without spending a lead record meant disabling the gate in the local page config only — nothing on the server changed. That distinction is worth preserving when you test anything commercial.

The implementation also lives inside the tool’s existing script rather than in a separate file, so it reuses the same API helpers and the same scoring prompt the interface uses. A standalone file would have meant duplicating the prompt, and duplicated prompts drift.

Should you implement WebMCP yet?

Honestly: probably not as a priority, unless being early is itself worth something to you.

Native support is not general. You will not see agent traffic yet, and anyone claiming measurable results from WebMCP today should be asked how they measured it. We cannot tell you it brought us anything, because it cannot have.

What it is worth right now is narrower and more defensible. It forces you to describe your own functionality precisely enough for a machine to use, which is a useful exercise regardless. It surfaces cost and authorisation questions you’ll have to answer eventually. And the work is small — the hard part was the thinking about entitlement, not the code.

If your site is primarily content, do the citation measurement and structural work first. That has a return today. Treat WebMCP as the next layer, not a replacement for the one underneath it.

Frequently asked questions

Is WebMCP the same as MCP?

They share a conceptual model but not the transport. MCP covers the wider server ecosystem and uses JSON-RPC; WebMCP covers tools declared by a page and executed in the browser. Implementing one does not give you the other.

Do I need to change server headers to support it?

Not for a same-origin implementation. The tools permissions policy defaults to self, so a page declaring its own tools works without configuration. Exposing tools to other origins is where that changes.

Will WebMCP affect whether AI engines cite my content?

There is no evidence it does, and we would be inventing a mechanism if we claimed otherwise. Citation is about whether your content is retrievable and extractable. WebMCP is about whether your functionality is callable. Related goals, different machinery.

What’s the risk of exposing a tool to agents?

The two real ones are cost and consequence. Anything that bills per call needs a cap or an entitlement check, because agents retry. Anything that writes, sends or deletes needs a human in the loop — the consequentialHint annotation exists for exactly that, and a read-only tool is a much safer first move.

If you’d rather have someone work through which of your own functionality is safe to expose, and in what order, that’s the kind of thing we scope as a project.