WebMCP Validator

What the WebMCP Validator checks

The Validator reviews a public implementation as evidence, not as a blanket certification. It checks the HTTPS origin, current document.modelContext references, imperative registerTool() calls, declarative form attributes, semantic labels, structured data, robots policy, sitemap context and optional llms.txt signals. It also reports likely user actions such as search, support lookup, quote, booking and checkout so teams can see whether the proposed surface matches the real page.

Static validation versus runtime validation

Static validation reads downloaded HTML and same-origin scripts. It can find a missing label, an old API reference, a duplicate-looking action or a form that lacks clear semantics. It cannot prove that a tool registers after hydration, that an authenticated user is authorized, that an endpoint returns the expected shape, or that a confirmation stops a dangerous commit. Runtime status is therefore shown separately. In this deployment it remains NOT RUN unless a controlled browser test is configured.

How to interpret errors

A failed HTTPS check means the page is not in the secure context expected by the API. A missing current API signal means no implementation was found in downloaded source; it does not mean the application cannot add one. A missing declarative signal means forms have not been annotated with their purpose. A semantic-form error points to labels or accessible names. Safety warnings mean the page contains an action that needs a confirmation and server authorization review, not that the workflow is automatically unsafe.

Recommended fix order

Start with one read-only workflow and give it a stable name, clear description and strict schema. Add labels and keyboard-complete forms. Register through the current documented surface or annotate a suitable declarative form, then connect the handler to existing application logic. Validate input twice, keep authorization server-side and preserve the human UI. After that, test navigation cleanup, network errors, cancellation, duplicate registration and the exact confirmation point for consequential actions.

What the Validator does not claim

A score is not browser compatibility, legal compliance, security certification or proof that an agent completed a task. Optional signals such as llms.txt, custom manifests and schema.org actions can aid discovery, but they are not official WebMCP requirements. Use the browser-support reference for the reviewed documentation status and the Simulator to map a concrete goal to a candidate tool.

Next step after validation

Use the Generator for a reviewable code scaffold and the Autopilot for prioritisation. If the action touches accounts, customer data, money, bookings or regulated workflows, request a scoped review through the Implementation Service.