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
- Agent access. Whether the page responds, whether it uses HTTPS, whether robots.txt allows the relevant agents, and whether there's a noindex that shouldn't be there.
- WebMCP tools observed in the browser. How many actually register, how complete the parameter schemas are, and whether the origin trial token is valid for that origin.
- Discoverability. The manifest at /.well-known/webmcp, the content type it's served with, and the quality of the descriptions. This category is explicitly marked as a community convention, not part of the official specification.
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.