What is WebMCP?

The plain-English guide to the browser-side Model Context Protocol — and the 121 sites already using it.

WebMCP lets a website give AI agents a set of named tools instead of a wall of HTML. A site registers tools on navigator.modelContext; an agent running in that tab discovers them and calls them by name, with typed arguments and a real return value. It is the difference between an agent guessing which button is "Add to cart" and an agent calling add_to_cart({ sku, quantity }).

WebMCP vs MCP: what actually differs

The Model Context Protocol (MCP) standardised how an AI client talks to a tool server. It works, and it is why every serious AI product now ships an MCP server. But an MCP server is a second system: you host it, you authenticate it separately, you keep it in sync with the product, and your users have to install and configure it.

WebMCP moves that surface into the page. The tools run in the browser tab the user already has open, which means:

• Auth is already solved. The user is signed in. The agent acts within that session — no API keys to mint, store or leak.
• Permissions are already scoped. Whatever the user can do in the UI is what the agent can do. Nothing more.
• Nothing new to host. The tools ship with your front end, so they can never drift out of sync with it.
• The user can watch. Actions happen in a visible tab, not in an invisible server-to-server call.

MCP and WebMCP are complements, not rivals. A backend integration for headless automation is an MCP server's job. Letting an agent operate the app a human is already looking at is WebMCP's.

How WebMCP works

Three moving parts:

1. The page registers tools. Each tool has a name, a description, a JSON Schema for its inputs, and a handler function.
2. The agent discovers them. A WebMCP-aware agent — a browser extension, an agent runtime, or eventually the browser itself — reads the registered tools when the page loads.
3. The agent calls them. Arguments in, structured result out. The page decides what is allowed, what needs confirmation, and what is off limits.

Adding WebMCP to your site

The minimum viable version is one tool. Start with the single action your users most often ask for, and wrap the function you already have:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the catalog and return matching products.",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string", description: "Free-text search terms" },
        limit: { type: "number", description: "Maximum results", default: 10 }
      },
      required: ["query"]
    },
    async execute({ query, limit = 10 }) {
      const results = await searchCatalog(query, limit);
      return { content: [{ type: "text", text: JSON.stringify(results) }] };
    }
  });
}

Three rules that separate a useful WebMCP surface from a frustrating one:

• Name tools after intents, not routes. book_appointment, not post_form_3.
• Write the description for a stranger. The agent has no product knowledge; the description is the whole spec.
• Gate anything irreversible. Reads can be free. Purchases, sends and deletes should require an explicit user confirmation in your own UI.

How this directory detects WebMCP

When you submit a site, a Cloudflare Worker fetches the URL and scans the HTML plus its same-origin scripts for three things: use of navigator.modelContext, registerTool call sites, and a descriptor at /.well-known/mcp.json. If any of those turn up, the listing publishes immediately and we record the tool names we could read.

Detection is evidence, not proof. Tools registered only after sign-in, or from a heavily minified bundle that builds names at runtime, will not show up — which is why a miss puts the submission in a review queue rather than rejecting it.

WebMCP FAQ

What is WebMCP?

WebMCP is a browser API that lets a website hand its own tools to an AI agent running in the page. The site calls navigator.modelContext to register named tools — search_products, create_invoice, book_room — and any WebMCP-aware agent in that browser tab can call them directly instead of guessing at the DOM.

How is WebMCP different from MCP?

MCP connects an AI client to a server over stdio or HTTP, with its own auth and its own hosting. WebMCP lives inside the page the user already has open, so it inherits the session, the cookies, the permissions and the rate limits the user already has. No API keys, no separate server, no second copy of your auth logic.

Do I need to build an MCP server to use WebMCP?

No. WebMCP tools are registered in JavaScript on the page. If you already have front-end functions that search, filter or submit, wrapping them as WebMCP tools is usually a few dozen lines.

Which browsers and agents support WebMCP?

WebMCP is an early W3C Web Machine Learning Community Group proposal. Support today comes through browser extensions and agent runtimes that inject the navigator.modelContext shim, rather than from shipping browser builds. Registering tools is safe either way — agents that do not understand them simply ignore them.

How does this directory verify a listing?

A Cloudflare Worker fetches the submitted URL, reads the HTML and its same-origin scripts, and looks for navigator.modelContext usage, registerTool call sites and a /.well-known/mcp.json descriptor. Sites where we find a real surface are published automatically with the tool names we could read. Everything else waits for a human.

Does it cost anything to be listed?

Submitting a site is free. Sites that pass automated WebMCP detection are published automatically.

Browse the directory

121 WebMCP-enabled sites exposing 363 tools are listed here. Browse them all, filter by category, or add your own — submission is free.