Agents are learning to use the web the hard way.
Today, an agent that wants to use your app reads the screen and simulates clicks. WebMCP gives it a better path: your app exposes typed tools, and the agent calls them. is the tooling for building that surface, and for keeping it safe.
Why this exists
WebMCP is early. It runs today in Chrome behind a flag, and most apps have nothing for an agent to call yet. But the direction is clear: apps will expose tools, and agents will use them the way people use interfaces.
The catch is that someone has to author those tools, and the naive version of that goes badly. Point a generator at an API without thinking and you ship payment webhooks, admin endpoints, and auth flows as things an agent can call. The interesting problem was never can an agent call your app. It is what it should be allowed to call, and who decided.
exists to make WebMCP practical for real applications. Not a single tool, but the tooling for the whole lifecycle of an agent-facing surface, built so developers stay in control of what agents can actually do.
The lifecycle
One loop, from spec to production.
The first five stages work today: @webmcp-stack/codegen generates the tools, its dashboard lets you understand and test them, the audit pass reviews them, and config keeps you in control. @webmcp-stack/telemetry and @webmcp-stack/audit close the loop: see how agents actually use your tools, and check any site’s WebMCP surface with a URL. One stack, not a pile of unrelated utilities.
Principles
The generated code belongs to you
Real files in your repo, no runtime dependency, no lock-in. Inspect them, modify them, delete the generator and keep the files. shadcn-style energy, not a runtime you rent.
Safety first
Giving agents access to application actions is a new security surface. The stack treats it that way: every tool is classified, risky tools start disabled, and the audit blocks what should never be an agent tool at all. You decide what to expose; the tools enforce the decision.
Open-source first
Everything here is genuinely useful on its own and self-hostable. If a hosted service ever exists, it adds convenience: collaboration, analytics, observability. It never gates the core developer experience.
Who is building this
Sourav
Product engineer
Hi, I’m Sourav, a product engineer. I’ve spent the last few years building for small teams (Paragraph, Pimlico, Gallery, RabbitHole) and working on my own things.
I started while making BeenThere agent-native. Generating tools from a spec turned out to be the easy part. The harder problem is everything around the generation: knowing which endpoints should never become tools, reviewing what an agent will see, and staying in control of the surface after you ship. That is the problem this stack exists to solve.
is open source and open in direction. If you are building with WebMCP, or figuring out what agents should be allowed to do in production, come say what you need.