Ayal Karmi
At nekuda, we’re hosting WebMCP creator Alex Nahas on the WebMCP Directory blog. Here is an abridged version of his essay on why the browser is a natural home for AI agents, and what the web still needs to make that work.
By Alex Nahas
A little over a year ago, I was attending Cascadia JS here in Washington. WebMCP had just gotten approved as a community group, and I was about to leave my job to work on MCP-B full time. RL Nabors was headlining a talk titled “death of the browser.”
The thesis: humans will delegate their web tasks to agents, so the browser will be replaced by something more agent native.
When I pitched WebMCP, the reaction was: “why are you putting money into a car that is about to be repossessed? Agents don’t need the browser, they need MCP, or a CLI, or an API.”
Agents do need those things. I just think the conclusion is backwards. Write down what an agent needs to be safe and useful, and you get things the browser already does, plus things it doesn’t do yet. That second list is what WebMCP is about.
The vast majority of services never shipped an MCP server, and they have no reason to. They have a website.
So what is a browser?
It’s easy to think of a browser as a thing that renders UI. But UI is only one facet. A more useful way to think about it is as a platform where the hard problems are functionally solved: discovery, distribution, sandboxing, identity.
Sandboxing means this code is not allowed to read that data, period. Authentication needs a place to hold credentials away from dynamic client side code. A cookie jar lets the browser attach a session cookie to a request for you.
How do I find software? Use a search engine, then load it without configuring or manually downloading anything. How do we know whose software we are using? HTTPS, DNS. Browser profiles let you segment identities. As a consultant, this might be the single best feature the browser has.
We had user agents a long time before we had agents.
But do agents need it?
Let’s start from first principles. You want to delegate things to your agent and be done with it. Fair enough. What does it need?
An api client? No problem! MCP does that. Authentication? We don’t want the agent to have credentials directly. Let’s make an MCP host. Discovery? Let’s create a registry!
Permissions? Let’s pop a dialog before every tool call. Oh, and a “don’t ask again” checkbox. Oh, and now people want a settings page to undo it.
Code execution needs a safe place isolated from credentials. UI needs a sandboxed iframe, with the host holding the token. People want plugins? Each gets a manifest, a permission model, and a place in a store. Every single thing on that list has been in the browser for over a decade.
Congratulations! You built a browser
But you’re still missing urls to share app state, passkeys, a back button, and tabs: parallel sessions the user can see and switch between.
And incognito. The more agent memory features ship, the more you want a session with no state and no memory.
And enterprise policy. IT can push a policy to 10,000 browsers that locks down which extensions and sites they can use. Try doing that to a fleet of agents.
So what happened to MCP?
MCP started with local tools, remote services, and later UI. Local went to bash: why wrap git when the model already knows git? Remote went to the api. UI went to the browser: MCP Apps is a sandboxed iframe talking to the host over postMessage.
The part that held up is the auth. Your client id is a metadata document on your domain. The resource server points to its auth server, which publishes its own metadata. It’s the web’s trust model: domains, well-known urls, https.
The winds of change
Over the last few months, the browser went from being declared “dead” to making a pretty serious comeback. Anthropic added a browser directly inside Claude Cowork. OpenAI added a built-in browser to ChatGPT and Codex, then WebMCP support. Google introduced WebMCP in Chrome.
The interesting part is not that these companies suddenly love browsers. Once you give agents access to logged-in apps, tabs, permissions, navigation, and all the weird services that will never build an MCP server, you keep ending up back at the browser.
What the web needs next
The browser is already pretty close. But exposing tools is only the beginning. Real work needs permissions, continuity, and a proper human handoff.
WebMCP: The browser already runs the site’s code and holds the user’s session. WebMCP lets sites expose JavaScript functions and HTML forms as structured tools for agents to discover and call.
Identity and permissions: A login tells the site which user is there. It doesn’t tell it which agent is acting or what that agent should be allowed to do. Trusting one agent shouldn’t automatically mean trusting every agent using my browser.
Tasks that survive navigation: Proposed continuation tokens would let a tool operation continue across pages on the same origin, without reconstructing the flow every time.
A proper handoff to the human: Sometimes the user must answer a question, sign in, or approve something. The elicitation proposal explores that. An agent clicking “Approve” itself doesn’t mean a human approved.
Agents talking to the site’s agent: A website may already have an assistant that knows its products and business. My agent should be able to ask it for help.
Letting the user choose the agent: Assistants from the browser, an extension, and the site may all try to help at once. The browser needs to coordinate them around the user’s preferences.
We already have the sessions, the sandbox, and a place for the user to step in. The next step is to give agents a clear place in that same system.
