What it is, how to implement it, how to verify it. Services AI agent readiness audit WebMCP Implementation Agentic SEO architecture Structured data and schemas API optimization and data layer for AI Knowledge graph and entity modeling WebMCP migration and refactoring WebMCP consulting for companies and agencies WebMCP for online stores Origin trial and technical compliance WebMCP maintenance and monitoring See all services Blog Leaderboard RO EN

Methodology: how we verify WebMCP

This page explains exactly how the validator on this site works, what it scores and what it refuses to score. We're publishing it because WebMCP validator methodology is the one thing that separates a useful check from a made-up grade.

How we test

We load your page in a real Chrome browser running on our server. We don't download the page source to search for text in it, we let the page actually execute.

Before the page's first script runs, we install an interceptor over the modelContext API. From that point on, we record every call that registers a tool, including its name, description, and parameter schema.

We then scroll the page and simulate interaction, because many performance modules don't fire their scripts until the visitor's first move. A checker that skips this step misses correct implementations.

What we score

The final grade blends four dimensions, each with its own weight. The maximum is 100.

  • Agent access, 22 points. Whether the page responds, whether robots.txt allows the relevant agents, whether an llms.txt file exists and whether a noindex is needlessly blocking the page. Separately, with no points, we recommend that robots.txt names the AI crawlers explicitly: it does not change what they may do, but some testing tools check for it.
  • WebMCP tools observed in the browser, 46 points. How many actually register, how well they are written, and whether the origin trial token is valid for that origin. Every tool is scored on its own, against six criteria, and the mark is their average: a snake_case name, a description that is a real sentence, a description that says what the tool returns, an object input schema, described parameters and constraints on those parameters. This category also gives 3 points for declarative form fields (name, type, required and a value constraint on every field; anti-spam traps are not counted) and 3 points for tool names made of a verb and the object of the action, for example search_products.
  • Coverage, 20 points. We open up to nine inner pages, not just the entry page. We score how many of them expose tools and, more importantly, whether the surface changes from page to page. A site that exposes the exact same list everywhere has tools as a header, not as a capability tied to where the agent actually is.
  • Discovery, 12 points. The manifest at /.well-known/webmcp, the content type it is served with and whether it describes the tools. This category is explicitly marked as a community convention rather than part of the official specification, which is why it carries the least weight.

What we deliberately don't score

We don't score whether an agent can complete a task on your site end to end, user confirmation flows, or the quality of the responses it receives. These require a real agent session, not a scan.

We also don't score APIs that have nothing to do with WebMCP. A site can be perfectly ready for agents without using other experimental browser features, and deducting points for that doesn't measure WebMCP readiness.

Whatever can't be checked remotely appears in the report in a separate section, marked as unscored. We don't count it as a failure.

What attributes actually exist in the spec

The declarative part of WebMCP uses a narrow set of attributes, documented by Chrome:

  • toolname, on the form
  • tooldescription
  • toolparamdescription, on fields
  • toolautosubmit

Anything else is made up. We've seen checkers deduct points for attributes that don't appear anywhere in the official documentation. A site that added them would gain nothing, because the browser doesn't read them.

Why static checkers get it wrong

A checker that downloads the page source and searches for text in it can't see what happens at runtime. WebMCP tools register through JavaScript, so they don't appear in the source when the script is deferred, bundled, or base64-encoded by an optimization module.

The result is a false negative: the site works, but the report says it has nothing.

Real examples we measured

We compared reports from public checkers with what we observe in real Chrome, on the same pages. A few situations we ran into:

  • A site registering three tools, confirmed in the browser, got the report "registerTool not found" and zero points on the entire imperative category.
  • The same page, which contains a visible form, was reported with "no HTML form found on this page."
  • The same site had a valid, decodable origin trial token with the correct origin. The checker didn't mention it at all.
  • Seven points deducted for missing an attribute that doesn't exist in the Chrome specification.
  • Ten points deducted for the absence of a browser API unrelated to WebMCP.

That site received a "poor" grade from a static checker, even though its implementation is complete and verifiable. We're not naming names, because the goal isn't to attack anyone, it's to show you what to check for in a report.

How to recognize a serious checker

  • It states explicitly whether it ran the page in a browser or just read its source.
  • It separates the official specification from community conventions and doesn't mix them into the same score.
  • It doesn't penalize you for attributes you can't find in the official documentation.
  • It decodes the origin trial token and tells you which origin it's valid for and until when.
  • It states what it can't verify, instead of marking everything as a failure.

Our limitations

We scan a single address per request, so tools that only register on other pages won't show up in that address's report. This is the correct behavior, since tools are page-specific, but it's worth knowing when you compare results.

If your site serves different content depending on region, or blocks automated traffic, the result may differ from what you see in your own browser.

We are not a certification authority and we don't issue WebMCP certifications, because no such thing exists.

If we got something wrong

If our report says something you can prove is false, we want to know about it. Send us the address and the report link through the contact page.

We'll fix it and let you know when it's done. A validator is only useful for as long as its results hold up to scrutiny.

You can run a free check anytime from the homepage, or check out our services if you'd like us to implement WebMCP for you.

Methodology versions

When we change the scoring rules we say so here, and every report carries the version it was graded under. An old report stays readable under its own rules rather than today's. We do not re-grade reports that were already issued.

  • Version 2.1, 13 September 2026. We added two scored checks to the tools category, 3 points each, taken from schema quality (down from 20 to 14): declarative form fields and tool names made of a verb and an object. AI crawlers named explicitly in robots.txt show up as a recommendation with no points, because naming them does not change what they may do.
  • Version 2.0, 13 August 2026. We added coverage as a separate dimension and started opening several pages instead of only the first one. We tightened how descriptions are scored: it used to be enough for a description to exist, now it has to be a real sentence and it has to say what the tool returns. The reason for the change: of the first thirteen scans, ten came back A+, and a grade almost everyone gets says nothing about the site and helps nobody improve.
  • Version 1.0, July 2026. Three dimensions, a single page scanned.