Every free tool on this site now registers itself as a WebMCP tool. An agent in the tab can call our schema validator, the five JSON-LD generators, the keyword density counter, the UTM builder, the slug generator, the word counter, the HTML to Markdown converter and the title pixel measurer directly, rather than filling in a textarea and scraping the result back out of the page.
Some of what we measured while building it makes that announcement smaller than it sounds, so the measurements are below too.
What WebMCP actually is
A page calls document.modelContext.registerTool() and hands over a name, a
description, a JSON Schema and a function. An agent running in that tab reads the
declaration and calls the function. No DOM guessing, no screenshot loop, no
selector that breaks when a class name changes. The function runs inside the page
as the signed-in user, so the site keeps its own session, permissions and
validation.
It is a W3C Community Group draft, not a ratified standard, and any reader can check which of those it is.
Three measurements that change what you should build
Almost nothing calls these tools yet. A site that shipped WebMCP tools on 23 February 2026 recorded zero external agent calls in the next 93 days. Mainstream agents still scrape and screenshot on arbitrary sites. Analyst timelines point at mid-2027 for anything resembling mass adoption. So nobody honest can sell WebMCP as a traffic source right now, and we are not.
Registration is already a commodity. Cloudflare ships a dashboard toggle that injects a bridge script at the edge with HTMLRewriter, no origin change at all. Shopify turned WebMCP on by default for Liquid storefronts on 21 August 2026. We checked two Shopify stores while writing this and both serve the adapter and an origin trial token. If your entire plan is "call registerTool", a switch already did it.
The hard part is which functions you expose, not how. Ten lines of code register a tool. Deciding that a given function is safe for an agent to call in a loop is the actual work, and it is where we spent our time.
The tool we deliberately did not expose
Our free AI visibility check spends real money at a provider on every call. It has no session, because it runs before signup, so there is no account to charge. A hard global ceiling in code stops that endpoint bankrupting us, checked before the spend and recorded after it.
That ceiling would have held if we had exposed the check as a tool. We left it out anyway. The ceiling protects the money, not the funnel, and an agent that can call something in a loop will burn the day's allowance long before a human buyer reaches it. Every tool we did register is pure: no network, no provider cost, no session. An agent can call all twelve a thousand times and it costs us nothing, which is the only reason exposing them to an anonymous caller is defensible.
One tool does fetch a URL the caller supplies: our free page check, which predates the twelve and is registered on every page. Fetching an arbitrary URL for an anonymous caller is our bandwidth and an SSRF surface, so that one runs behind a guard that resolves public hosts only and re-checks redirects, plus a per-IP rate limit. It spends nothing at a provider, which is what keeps it on the safe side of the line. The rule is about cost and blast radius rather than about fetching, and a tool that fetches still has to earn its place.
The verification mistake we made, twice
document.modelContext does not exist in a stock automated browser. So a check
that visits a page and finds no tools returns exactly what a broken page returns,
and exactly what a broken checker returns. A negative result from an instrument
that has never reported a positive is not evidence of anything.
We hit this in the obvious way and then in a subtler one. The first time we
tested with a recording stub, and made the stub prove it could see a
POSITIVE_CONTROL tool before trusting it about our own. That worked.
The second time we asked an agent to verify the live site. It reported no WebMCP, cleanly and confidently, and its own output contained the reason: it was driving Chrome 145. The implementation does not exist before Chrome 149. That run could not have detected WebMCP on any site in the world, and it concluded something specific about ours.
The fix is a control that must succeed. Any Shopify storefront will do, because Shopify enables WebMCP on those by default. If a browser cannot see WebMCP on a Shopify store, the browser is the problem and the test is over. Check the control first, and stop when it fails rather than reporting on the site you meant to test.
One thing that is not real
Several "agent readiness" checkers look for /.well-known/webmcp. That path is
not in the specification. A checker invented it, and it spread. If a tool marks
your site down for missing that file, it is measuring something the spec never
defined, and adding the file will not make a single agent call a single tool.
Ours is a header, which is what the origin trial actually requires, plus the
registerTool calls on each page. There is no file to add.
What this is worth today
In a browser with WebMCP enabled, an agent can operate twelve of our tools directly instead of scraping them, plus the free page check that was already there, which is thirteen in total. Outside that browser, nothing changed, and that is most people. Our origin trial token covers Chrome 149 to 156 and expires on 17 November 2026, which we track in code so the day it lapses is a build failure rather than a silence.
We shipped it because the declaration is cheap and permanent, the browsers are moving, and the work of deciding what is safe to expose is better done now than under deadline. No agent has called any of it yet, and we will say so until that changes.
Correction, 28 August 2026. The first version of this post said we excluded every tool that fetches a caller-supplied URL. That was wrong. Our free page check does exactly that and was already registered before the twelve, which the author of the twelve had not found. It is defensible for the reasons above, and the original sentence was not. Fixing it in place rather than deleting it, because a post about verifying your own claims should show what happened when this one failed.