Protocol explainer

WebMCP: the page becomes the API.

WebMCP puts an MCP server inside the web page itself. A site registers JavaScript tools in the visitor’s browser — through the navigator.modelContext API — and any agent driving that browser can call them: structured actions like “add to basket” or “check availability” instead of guessing at buttons and forms.

It matters because the browser is where most of the web’s capability actually lives. A site that cannot run a server-side MCP endpoint can still hand an in-browser agent a typed, testable interface — and since August 2026, mainstream agents (ChatGPT’s desktop browser among them) consume exactly that.

Status in this index: WebMCP verification lands with our next crawl (September 2026). Verified entries will appear here, each dated, with the tools the page declared. Declared, then verified — never assumed: a script tag is tier-1 evidence, a tools list read live is tier 2, an agent completing an action is tier 3. This page practises what it preaches: knowngood.sh registers WebMCP tools of its own — find_capability and get_site_report — so a WebMCP-capable browser can search the verified index without leaving the page.

How Known-Good verifies WebMCP

Our probe treats WebMCP like every other capability: as a claim to be tested. The static pass detects the registration (navigator.modelContext / provideContext / registerTool) in page source — that records a declaration. A headless pass then loads the page and lists the declared tools without ever invoking them — that upgrades the record to probe-verified. Invocation is reserved for tier-3 behavioural verification, with the site owner’s consent.

Adding WebMCP to your site

navigator.modelContext.registerTool({
  name: "check_availability",
  description: "Free slots for a given service and date",
  inputSchema: { type: "object", properties: { date: { type: "string" } } },
  execute: async (args) => ({ slots: await lookup(args.date) })
});

Pair it with the readable layer — markdown negotiation and llms.txt — so agents that have not adopted WebMCP can still use the site. When your implementation is live, request a probe: placement is decided by the probe, never by the request.