What is WebMCP?

The problem it's trying to solve

AI browser agents — the kind that can navigate a website and take actions on a user's behalf — mostly work today by reading the page like a person would: looking at the rendered DOM, guessing which button means "add to cart," and clicking it. That works, but it's slow, brittle, and breaks whenever a site's layout changes.

WebMCP proposes a more direct path: a page can register a set of structured "tools" — named actions with a description and a typed input schema — that an agent can call directly, the same way a person uses a search box or a checkout button. The name is a nod to Anthropic's Model Context Protocol (MCP), which does the same thing for connecting AI assistants to external tools and data sources — WebMCP brings that same idea directly into the browser and onto the page itself.

How it actually works

A page registers a tool with a JavaScript call to document.modelContext.registerTool(), passing a name, a human-readable description, a JSON Schema describing the tool's inputs, and an execute function that runs when an agent calls it:

document.modelContext.registerTool({
  name: "search_products",
  title: "Search Products",
  description: "Search the product catalog by keyword",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "Search keyword" },
    },
    required: ["query"],
  },
  execute: async ({ query }) => {
    const results = await searchProducts(query);
    return { results };
  },
});

An agent visiting the page can then call document.modelContext.getTools() to see what "search_products" does and what input it needs, then invoke it directly — no clicking, no guessing at DOM structure. Access is gated behind a browser permissions policy (default: same-origin only), and tools only exist for the lifetime of the page that registered them.

Why it might be worth watching

• If AI agents become a meaningful share of how people browse and transact online, sites that give agents a reliable, structured way to act — rather than forcing them to screen-scrape — are likely to convert better with that traffic.
• It's a natural extension of the same instinct behind robots.txt, sitemaps, and structured data (JSON-LD): give machines an explicit, reliable interface instead of making them reverse-engineer your HTML.
• Being early costs little beyond attention right now — the spec is small, and adopting it doesn't require rebuilding anything, just describing actions your site can already perform.

Why you shouldn't rush it

The specification itself is still actively changing — its own declarative (HTML-attribute-based) API is marked as unwritten, there's no standard way for a site to declare WebMCP support ahead of a visit (no manifest file, no .well-known/ path), and it's implemented in exactly one browser, experimentally. Code you write against it today may need to change before it's stable. If your site doesn't have obvious agent-drivable actions (search, add-to-cart, book, apply), there's no rush.

How MarketMan checks for it

Starter and Pro plans include a best-effort WebMCP check on every SEO crawl. To be transparent about what it actually does: MarketMan's crawler fetches your page's HTML and a handful of same-origin linked scripts, then looks for textual signals of document.modelContext / registerTool( usage. Because there's no static discovery mechanism in the spec itself, this can't be a definitive yes/no — a "no signals found" result means we didn't find evidence in what we checked, not proof your site lacks it. Confirming for certain would require executing your site's JavaScript in a real browser, which the check doesn't do (today).

Further reading

• The official WebMCP spec draft (W3C Web Machine Learning Community Group)
• webmachinelearning/webmcp on GitHub — the spec source and issue tracker
• modelcontextprotocol.io — the broader Model Context Protocol WebMCP is named after