How our checks work
What we look for, what your results mean, and where a website check has its limits.
Enter a public page URL. We review its code for tool declarations, then load the page to discover tools registered with WebMCP. You get one result with the evidence behind it.
JavaScript function discovery and connections
Find tool ideas includes a separate static JavaScript evidence review. This is distinct from the checker’s detection of existing WebMCP registrations.
Tool-idea scans inspect public inline scripts, event-handler references, and up to four same-origin linked scripts. Function names, parameters, and source locations are evidence, not proof of behavior or runtime availability. No discovered functions are called during scanning.
- Up to 20 inline scripts and 20 elements with click, submit, or change handlers are reviewed.
- Up to four same-origin linked scripts are fetched, with a 192 KiB size limit and a three-second timeout per fetch.
- At most 20 function evidence entries are returned. Unparseable, oversized, dynamically loaded, or cross-origin code can be missing.
- Public assignments, declarations, module-private functions, and event-handler references are distinguished. All entries remain unverified.
Function bodies and literal values are excluded from the JavaScript evidence sent for AI recommendations. Names and parameter names do not establish authorization, output shape, or side effects.
The builder can export an adapter for a function exposed on window or globalThis. Choose an inputs object or separate arguments in field order. Private and module-scoped functions need a public adapter. Install the export on your website before testing it in Playground. Functions that change data require confirmation; cancellation cannot undo their effects.
First, we review the page
We read the public HTML, inline JavaScript, and up to eight directly linked JavaScript files. We look for WebMCP registration calls and forms annotated as tools, then validate the input schemas we can read.
A declaration is a clue, not proof that a tool is available. Some code is conditional, runs only after interaction, or never runs at all. Form schemas inferred from HTML are also approximations.
Then, we check what’s available
We open the page in a fresh Chromium session with WebMCP enabled. The page’s JavaScript runs as it loads, and we read the tools exposed by its native WebMCP API.
We watch for late registrations for up to 30 seconds. A non-empty tool list can finish earlier once it has settled. This gives slower pages time to register tools without making every check wait the full two minutes.
We never execute the discovered tools. A tool might still fail when called, require permission, or return an unexpected result. You can test tools separately in the playground.
Reading your result
- Tools found during this check
- We observed registered tools on the checked page. Additional source declarations are labelled separately when their availability was not confirmed.
- No WebMCP tools found
- No tools were discovered in the content we inspected. Any coverage limits are shown alongside the result. This does not establish that every page on the website has no tools.
- Tool availability not confirmed
- We found declarations in the page code, but could not confirm registered tools.
- Availability check incomplete
- A later step did not finish, or the two checks reached different pages. Earlier findings stay visible with an explanation.
- This website blocked the automated check
- We detected a clear bot-protection or human-verification page. We do not bypass the challenge.
- Website check failed
- The check could not finish and had no earlier tool findings to preserve. You can try again.
Which page did we check?
We check the URL you enter, following permitted redirects. We do not crawl the rest of the website. If your URL redirects, we show the entered URL and the final page checked.
If the source review and browser check land on different pages, their findings stay separate. Tools inside embedded frames are excluded, and pages with frames show a coverage notice.
What can be missed?
- Tools available only after sign-in, consent, or another interaction.
- Tools registered after the observation window or inside embedded frames.
- Declarations in imported modules that the source review does not follow.
- Content beyond our request, size, or time limits.
Browser loading blocks images, fonts, media, WebSockets, service workers, and non-GET requests. These restrictions can affect page behaviour. Your visitors may also have different browser support.
Waiting, timeouts, and retrying
The full check has a 120-second limit, with shorter limits for individual requests and stages. After 90 seconds, we let you know the site is taking longer than usual. Checks stop automatically when their deadline is reached.
Results are snapshots. Tools may change when the page updates or someone interacts with it. Use “Check again” to get a new snapshot of the original URL.
Your session and data
We use a fresh browser session, not your signed-in browser. No browser login session is sent to the checker. URL inputs and results stay in page memory. Recent check summaries are saved in your browser and can be cleared from Recent checks. Our service requests the submitted page and allowed resources from their hosts.
Use public URLs without passwords, access tokens, or private information. “Try an example” displays sample data; it does not run a live check.