The Infrastructure Problem Nobody's Talking About: Why WebMCP's Missing Piece Actually Matters

I spent two hours last week debugging why an AI agent couldn't find a specific action on one of my client's web apps. The agent kept trying to scrape the UI instead of calling a perfectly good API endpoint I'd exposed. The real kicker? There was no way for the agent to know that endpoint existed before landing on the page. It had to blindly explore, fail, and backtrack. That conversation stuck with me because it exposed something developers rarely discuss: infrastructure gaps in emerging standards matter as much as the standards themselves.

That's when I stumbled on what the WebMCP Registry team built, and it crystallized something I've been thinking about for months. They didn't just build a tool—they solved a discovery problem that will become critical once WebMCP gains real traction. And more importantly, they built it before the problem becomes obvious to everyone else.

What WebMCP Actually Is (And Why It Matters)

WebMCP is a W3C proposal that lets your website declare what it can do directly to agents running in the browser. Instead of an AI scraping your DOM or making blind API calls, you register actual functions with schemas. The agent knows exactly what's available, what inputs are expected, and gets direct access to your application state.

For developers, this is genuinely interesting. It's cleaner than writing extensive backend APIs just for agent integration. It sidesteps the scraping problem entirely. But here's where most people stop thinking: how does an agent discover these tools before it even visits your site?

That's the gap. The spec tells you how to run tools in the browser, but not how to advertise them. An agent can query document.modelContext.getTools() once it arrives, but it's flying blind before that. For agents doing any kind of planning or routing decisions, that's a real limitation.

The Solution: Registry + SDK

The team built two complementary pieces that actually work together well. The WebMCP Registry is a public directory where developers register their domains and tool contracts. It's queryable, has DNS-based verification (which I appreciate—actual security thinking), and exposes an HTTP API that agents can use before even visiting your site.

The second piece is the npm package: @webmcp-registry/kit. This is where the developer experience shines. It gives you defineTool with Zod schema support, React hooks for registration, and a CLI that handles syncing tool contracts automatically.

I like that they didn't try to make this complicated. Your tool definition looks clean:

import { defineTool } from '@webmcp-registry/kit'
import { z } from 'zod'

export const addTodoTool = defineTool({
  name: 'add-todo',
  description: "Add a new item to the user's active todo list",
  kind: 'write',
  input: z.object({
    text: z.string().describe('The text of the todo item'),
  }),
  handler: ({ text }) => {
    const todo = addTodo(text)
    return { added: todo }
  },
})

No manual JSON schema writing. No boilerplate. The Zod schema becomes your contract, and the handler is just a function. When you drop it in a component with useWebMCPTools(), it registers on mount and cleans up on unmount.

Where My Brain Got Stuck

Here's what I genuinely appreciated: they thought through the hard parts. Component-bound handlers that need state access? They have defineToolContract for splitting schema from implementation. Browser support not ready yet? Silent no-op in production, loud warning in development. Single CLI command to sync changes on deploy.

But I have questions. The registry uses DNS verification, which is solid, but what about trust and abuse? Who decides if a tool description is accurate? What happens when developers register tools they never actually implement properly? I assume there's some kind of validation, but I don't see that discussed.

Also—and maybe this is premature—what's the performance story when agents start querying registries at scale? Is there caching? CDN? Rate limiting? These aren't implementation details for later; they matter now if you're building infrastructure that's supposed to handle production agent traffic.

What This Means for People Building Real Things

If you're building a web app with meaningful user interactions that an AI agent might want to automate, this infrastructure becomes valuable sooner than you think. You can define your tools once and have them discoverable to any agent using the registry.

The timing feels right too. WebMCP is still behind a flag in Chrome, so there's a window to build the ecosystem before the demand spike. This is exactly when you want your infrastructure ready—before everyone needs it.

My Next Question

Are you building anything where agent integration would make sense? I'm curious whether this approach would feel natural in your stack, or if you'd find yourself pushing back against the abstraction. Would you actually use a public registry, or would you prefer agents connecting directly to your endpoints?

Source: This post was inspired by "We built a public registry and SDK for WebMCP tools. Here's why it matters." by Dev.to. Read the original article