If you haven't come across WebMCP yet, the quick version is this: it's a W3C proposal that lets a web page register callable actions directly in the browser using document.modelContext. Think of it as an in-browser MCP server. Instead of an AI agent scraping your UI or talking to a separate backend, your page declares what it can do, and the agent calls those actions directly with the user's active session and current state already in scope. Sylwia Lasek wrote a great first-look piece on it here if you want to understand the fundamentals before going further.

The problem we noticed is that the specification addresses how tools run in the browser, but it doesn't address discovery. An agent visiting a page can query document.modelContext.getTools() once it gets there, but it has no way of knowing what tools are available on any given site before loading it. That gap matters for agents that need to plan ahead, inject tool schemas into a system prompt, or decide which sites are worth visiting at all.

So we built two things.

The WebMCP Registry is a public directory at webmcp-registry.dev where developers register their domains and tool contracts. It's queryable by keyword, category, or domain, it has a verification system based on DNS TXT records, and it exposes a public HTTP API so agents can look up what a site can do before visiting it. The registry also registers its own tools using WebMCP, which felt like the right move.