WebMCP is available experimentally through an origin trial, exposing typed tools through navigator.modelContext instead of relying on agents to scrape and click through the page. The approach seems promising, but there doesn't appear to be much demand-side adoption yet: browsers can register tools, while relatively few agents seem to call them in production. Has anyone shipped a WebMCP tool contract on a real site? If so, did it receive meaningful usage, was the implementation worth the effort, and how are you deciding which actions to expose as tools versus leaving as regular UI interactions?
4 Answers
I’d treat it as an experiment rather than a production dependency right now. Implementing early can still be worthwhile if you want to influence the API, learn how it fits your framework, and be ready if browser-based agents start using it at scale. For choosing tools, start with user goals: map out the task, imagine the conversation between the user and agent, and then expose only the functions needed to move through those steps. Talking through several realistic scenarios with users or a UX teammate can help reveal the right boundaries.
The lack of awareness is probably a stronger signal than the technical promise at this point. Even developers who follow AI and web platform work closely may not have encountered it yet, and the API is still experimental. There are some early integrations and growing interest from both site developers and agent builders, but it’s too soon to judge adoption by production traffic. I’d prototype a small, high-value workflow rather than invest in a broad tool catalog.
It’s still very early. The API isn’t generally available and the design is continuing to evolve, so widespread production usage shouldn’t be expected yet. The idea has potential because users could bring their own model and give it structured access to the page they’re currently using, without requiring a separate remote MCP server. The downside is that behavior may be difficult to make predictable when you don’t control which model is calling the tools.
That’s the main adoption question for me too. The use case is interesting, but broad support seems difficult until the API and the consuming agents become more stable.
There’s also ongoing discussion about bringing the idea into a broader web standard, which could help avoid every browser inventing a separate mechanism. Until there’s clearer cross-browser alignment and a reliable agent that calls these tools, keeping the implementation small and easy to remove is probably the safest approach.
That makes sense. Testing a narrow workflow now seems more useful than trying to expose every possible action before there’s a dependable consumer.