More and more agencies and development teams are looking for a tool that can quickly and unambiguously confirm whether a site correctly exposes tools for AI agents according to the WebMCP specification. Unfortunately, most WebMCP checkers available today rely on a simple text search in the page's source code, which produces wrong results in common situations, and often in the most important implementation cases. In this article we explain technically why this approach fails and what a correct verification actually requires.
Why simple WebMCP checkers get it wrong
A checker that limits itself to downloading a page's HTML and searching for certain strings starts from a false premise: that everything relevant to WebMCP is statically present in the initial markup. The reality of modern web applications is entirely different. Most tools are registered from executed JavaScript code, not declared directly in HTML, and this code can be produced, transformed, or delayed in dozens of different ways.
The result is predictable: pages that correctly implement WebMCP are reported as having no tools, while pages that merely contain incidental textual mentions can be wrongly marked as compliant. Both types of error are costly, since they lead either to unnecessary investigations or to a false sense of security.
What a WebMCP tool actually is
A WebMCP tool is not a simple static HTML attribute, but an object registered programmatically through the modelContext API available on that page. Registration happens through JavaScript code that calls specific methods, passes a name, a description and a parameter schema, and then connects an execution function.
This process can happen immediately when the page loads, but it can just as easily happen much later, conditioned on user actions or responses received from a server. For this reason, analyzing only the HTML structure means ignoring precisely the place where the essential part of the implementation happens.
Deferred scripts and the problem of delayed execution
Many modern applications use the defer attribute or dynamic script loading to optimize rendering speed. These scripts can run several hundred milliseconds after the document has been initially parsed, and it is exactly in that interval that WebMCP tool registration can occur.
A checker that only analyzes the raw page source, without actually executing the JavaScript, will never see this process. From such a tool's perspective, the tool simply doesn't exist, even though in the user's real browser it works perfectly.
Bundled and minified code from build tools
Almost all contemporary web projects go through a build process that combines, minifies, and transforms source files. Function names are shortened, code structure is rearranged, and calls to the modelContext API can appear in completely different forms compared to the code originally written by the developer.
A simple text search, looking for an exact function name or a specific call format, will almost certainly miss these implementations. The code is functional and technically correct, but invisible to a tool that doesn't understand the semantics of execution, only searches for character strings.
Base64-encoded content and other forms of obfuscation
Some applications load parts of their logic as encoded content, for example in base64, decoded and executed only in the browser. This technique is used both for security reasons and to reduce the size of certain resources transmitted initially.
For a text-based checker, such content looks like a random string of characters, with no visible connection to WebMCP. The only way to understand what's actually happening is to let the code run in a controlled environment and observe the result, not its raw form before execution.
Tools that only activate on interaction
A frequently encountered case is that of tools which only register after a user interaction, for example opening a modal, authenticating, or clicking a specific button. This practice makes functional sense, since not all tools need to be exposed all the time.
For a static checker that analyzes the page immediately after loading, these tools are completely absent from the report. The conclusion will be that the site offers no tools to AI agents, even though in reality they appear exactly when needed, that is, in the actual usage flow.
What intercepting the modelContext API means
A rigorous technical verification doesn't look at the source code, but positions itself inside the browser's execution engine and intercepts the actual calls to the modelContext API. In practice, the checking tool inserts its own observation code before any other script on the page runs.
This way, regardless of whether a tool's registration comes from a minified file, a deferred script, or code decoded from base64, the moment of the actual call is captured correctly. What matters is not the form of the code, but the real behavior observed during execution.
Why load order matters so much
If the API interception is installed too late, that is, after the page's first script has already managed to run, there is a real risk of missing early tool registrations. Many applications initialize their WebMCP logic in the very first lines of executed code.
For this reason, a correct tool must inject the observation mechanism before any other script on the page, not as a later stage of the analysis. This is a seemingly small technical difference, but one with a direct impact on the correctness of the final result.
The problem of invented attributes that don't exist in the specification
Another frequent source of confusion comes from checkers that search for certain HTML attributes supposedly specific to WebMCP, attributes that, in reality, don't appear anywhere in the official specification. These tools were probably built based on assumptions or on early, incomplete third-party implementations.
The result is a report that validates or invalidates a page based on a criterion that has no real connection to the actual functioning of the tools. A site can have zero attributes of this type and still have a fully functional modelContext API, or the reverse, it can have those attributes without them producing any real effect.
The consequences of a false positive or false negative report
A false negative report, meaning one that says no WebMCP tools exist even though they work correctly, can lead a team to unnecessarily redo an already successful implementation or to invest resources fixing a nonexistent problem. Lost time isn't the only consequence, reduced trust in the checking tool is another.
A false positive report is, in fact, even riskier. The site appears ready for AI agents, but in reality exposes nothing functional, and the problem is only discovered when a real agent tries to use those tools and fails.
How to recognize a rigorous checker
There are a few practical criteria you can check before trusting an automatically generated report. These aren't about marketing, but about the actual way the tool analyzes the page.
- It actually executes the page's JavaScript, in a real browser environment, not just static source code analysis.
- It intercepts the modelContext API before the page's first script executes, not after.
- It doesn't rely on invented HTML attributes, but on real tool registration calls.
- It waits a reasonable amount of time for deferred scripts and interaction-activated tools.
- It transparently explains what it observed, not just a simple correct or incorrect verdict.
If a tool can't explain why it reached a certain conclusion, that's a clear signal that its underlying methodology is most likely superficial.
What a correct audit report should contain
A useful report isn't limited to a simple "yes" or "no" regarding the presence of WebMCP tools. It should list every detected tool, with its name, the description used, and, where possible, the structure of the accepted parameters.
A rigorous report also mentions the moment each tool was registered, whether it appeared at initial load or later, following an interaction. This information is useful not only for technical validation, but also for teams working on a site's AI agent readiness audit.
The role of a correct checker in the development cycle
A checker that actually executes the code and correctly intercepts the API can be naturally integrated into the development process, not just used occasionally for a one-off report. It can be run before releasing a new version, precisely to confirm that changes haven't affected tool exposure.
This discipline is especially useful for teams going through a WebMCP implementation process from scratch, where configuration mistakes frequently occur even when the code looks, at first glance, correctly written.
When it's worth testing manually, not just automatically
Even the best automated checker doesn't completely replace a careful manual verification, especially in complex cases, involving authentication logic or tools conditioned on application state. Automation offers speed and repeatability, but doesn't always cover every real usage scenario.
We recommend treating the results of any automated tool as a starting point, not as an absolute final verdict. For critical situations, an additional verification performed by an experienced team remains the safest way to avoid surprises after launch.
Conclusion
WebMCP checkers that stop at a simple text search in HTML cannot reflect the reality of modern applications, built from deferred scripts, bundled code, and interaction-activated tools. A trustworthy verification executes the page, intercepts the modelContext API before any other script, and transparently explains what it observed. If you'd like a real technical evaluation of your implementation, you can start with a direct test in the WebMCP validator operated by our team.
