WebMCP: The Next User of Your Website is an Agent
A look into WebMCP, how your website can expose tools to AI agents natively in the browser, and what it means for frontend developers in 2026.
WebMCP: Your Website's Next User is an Agent
Earlier this year, WebMCP was annouced publicly as a new W3C web standard. This is different from MCP, which originates from Anthropic and was later donated to the Agentic AI Foundation (under the Linux Foundation). I immediately found the idea appealing as it solves a few problems we have today when agents try to interact with existing web pages.
But doesn't MCP already do this?
I had the exact same thought. Traditional MCP is great, but it usually runs over stdio or SSE. It's meant for desktop apps or local IDEs.
WebMCP is web-native. It lives right there in the browser, sharing your session and cookies. This means the AI agent inherits your authenticated state. So instead of an agent awkwardly trying to scrape your DOM or guessing which button to click, your web page registers native JavaScript functions or HTML forms as "tools". Your website essentially becomes the client-side MCP server.
Understanding the problem
If you ask an AI Agent to perform an action on a web page on your behalf, it needs a few things:
- A browser
- Authenticated accces
- To know what exists on the page
- To know what actions can be made on the page
The first two are a hassle to get going, and the last two consume a lot of your tokens and context window.
The idea of WebMCP is such that your ai agent already lives in your browser, so you athenticate normally. The the website itself registers tools that are exposed to the agent. The agent has a standard way of "discovering" tools and call them reliabliy, instead of parsing the DOM and guessing what to do.
How it works
There are two main ways to expose tools to an agent.
The Imperative API
The first way is using JavaScript. Here is a quick example of how you can register a tool using document.modelContext.
// Let's register a tool to add a todo item
await document.modelContext.registerTool({
name: "add-todo",
description: "Add a new item to the user's active todo list",
inputSchema: {
type: "object",
properties: {
text: { type: "string", description: "The text content of the todo item" }
},
required: ["text"]
},
async execute({ text }) {
await addTodoItemToCollection(text);
return {
content: [{ type: "text", text: `Added todo item: "${text}" successfully.` }]
};
}
});
The Declarative API
The second way is my favorite because it uses standard HTML forms. You just add a few specific attributes, and the browser turns your form into an executable tool for the agent.
<form toolname="search-cars" tooldescription="Perform a car make/model search">
<input type="text" name="make" toolparamdescription="The vehicle's make (i.e., BMW, Ford)" required>
<button type="submit">Search</button>
</form>
What I found really interesting is that you can actually style the agent's activity with new CSS pseudo-classes like :tool-submit-active. It's pretty cool to see the browser natively supporting this.
Security
Of course, the first thing that comes to mind is security. Because the agent operates using the user's authenticated state, a malicious tool could theoretically try to hijack the session. There's already a paper on "Mid-Session Tool Injection" that demonstrates this exact problem.
The Chrome team has published some hardening guidance, including using readOnlyHint and a requestUserInteraction() function for sensitive tasks so that a human is kept in the loop. We definitely need a better solution for this problem before it goes mainstream, but it's a start.
Baseline Status
Loading browser compatibility data...
As expected, it's still in origin trial in Chrome as of 10 July 2026, and other browsers haven't fully committed yet. So it's probably best to keep this behind feature flags for now.
Why though ?
So far we have approached WebMCP from the developer's perspective, but let's switch to a user's perspective.
Some websites try to offer 'chatbots' that can do stuff for you in their system. This feels different on every website and capabilities vary widely. It is my opinion, that instead of being provided with a different agent on every website, most users will have their own agent. Probably built-in their browser, who knows them and have their personal context. It feels much more natural to tell your agent to do an action, and have the website reveal tools to help your agent accomplish the task reliably.
How to use it today?
Until now, i've only been able to use it via the "WebMCP Model Context Tool Inspector" chrome extension. This provides a simple agent that can discover tools registered on a website. I expect this to ship in "Gemini in Chrome" soon and hopefully other browser ai agents like "Claude in Chrome".
Demos
Video coming soon
What's next
I think this opens up a lot of possibilities. Angular already has experimental support for WebMCP, but there's a gap for Vue and Nuxt. Maybe I will look into a composable to bridge the gap. useWebMCPTool() ?
