The Next Steps on the Web and WebMCP

A little over a year ago, I was attending Cascadia JS here in Washington. WebMCP had just gotten approved as a community group, I had just published the right place to build your MCP server is in your website, and I was about to leave my job to work on MCP-B full time. RL Nabors, who has been an active voice in the Web for a while now, was headlining a talk titled "death of the browser."

The thesis was as follows: most websites and the browser itself were meant for humans, but humans will opt to delegate their web tasks to agents. Therefore, the browser is going to be replaced by something more agent native.

At the time, this thesis felt like it was backed up by data. MCP was taking off across companies, tweets like "UI is pre-AI" were going very viral. People (myself included) were starting to pick services based on how accessible they were to agents. The browser was being opened and used less for work so it was not a stretch to say it was "dying." At this time, when I would pitch WebMCP to people, the overwhelming 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." A year later that is still the default bet. Salesforce announced Headless 360 this April, every capability exposed as an api, an MCP tool, or a cli. But look at who actually shipped an MCP server: developer tools and the big SaaS platforms. The vast majority of services never did, and they have no reason to. They have a website.

The thing is, they are correct about all of these things. Agents do need MCP, or a cli, or an api. I just think the conclusion is backwards. If you write down what an agent actually needs to be safe and useful, you get a list of things the browser already does, plus a short list of things it doesn't do yet. That second list is what WebMCP is about. So this post is two things: the case that the browser is the platform for agents, and what we need to add to it.

So what is a browser?

It's easy to think of a browser as a thing that renders the UI of a website. And the majority of the people claiming its demise are thinking of the browser exactly that way. But in reality, UI is only one facet of the browser. A more useful way to think about it is as a platform where the hard problems are functionally solved: discovery, distribution, sandboxing, identity, and a bunch of other things.

Side note: the HTTP spec has called the browser the "user agent" since forever. It's the piece of software that works for you, even when the site would prefer it didn't (ad blockers, pop up blockers, reader mode). We had user agents a long time before we had agents.

Let's go through them.

Sandboxing: A browser tab is the most well tested sandbox in existence. The lethal trifecta (private data, untrusted content, and a way to send data out) is XSS with a new name, and XSS is the reason the same origin policy and CORS exist. We have been dealing with this exact attack for 20 years and the fix that worked was making it so this code is not allowed to read that data, period.
Authentication: How do you authenticate the client without making that credential fetchable from dynamic client side code? A cookie jar. The code running in the tab never sees the session cookie, the browser attaches it to the request for you.
Discovery & distribution: How do I find the piece of software I want to use? Use a search engine, then load the software in the browser without having to configure or manually download anything!
Trust: How do we know whose software we are using and how do we know to trust them? HTTPS, DNS. If you go to google.com's domain, you know for a fact you get their site loaded in your tab, not someone else's. MCP ended up here too (more on that later).
Identity: Browser profiles let you segment identities while staying in the same browser. As a consultant, this might be the single best feature the browser has.

That's not to mention the fact that the browser also has: passkeys, bluetooth and serial APIs, a file system scoped by origin alongside databases scoped by origin, the ability to run machine code via WebAssembly, games and ML inference via WebGPU, file system access APIs to safely read and write local files, and that is just scratching the surface: https://howfuguismybrowser.dev/

But do agents need it?

Well I don't know, let's start from first principles. You've got your agent that you want to use for everything. You don't want to click around dashboards anymore, you just want to delegate things to your agent and be done with it. Fair enough. So what does this agent need?

An api client: We need some way to talk to external data and services. No problem! MCP does that, let's just have the agent spin up a local process to talk to the api!
Authentication: Huh, well we don't want the agent to have credentials directly, so we need some sort of way to put the credential in a place the agent cannot see it. Let's make an MCP host.
Trust: Oh shit! A bunch of third parties have made MCPs for stripe and our users are not sure which one to use! Let's just host our own remote one on our domain.
Discovery: Hmm, people are having a hard time finding our MCP and don't like the fact that they have to click a bunch of things to set it up in our agent. Let's create a registry for all the MCPs!
Permissions: People are getting nervous about tools doing stuff without asking. Ok, 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 the "don't ask again."
Code execution: We want our agent to call these tools with code, we need a safe place to run this code that is isolated from all these credentials!
UI: We also want the agent to run little programs with UI on our agent platform so the user can see and play around with them! Easy! Let's just serve the UI over MCP, render it in an iframe, proxy all calls through the host frame which holds the oauth token and we are good.
Isolation: We are going to need to protect these iframes from each other, let's double wrap them so we can control and isolate them!
Extensibility: People want to add their own stuff to the agent. Let's do plugins! Each one gets a manifest, a permission model, and we'll put them in a store.

Congratulations! You built a browser

Every single thing on that list has been in the browser for over a decade. But you are still missing:

An easy way to share app state with other people (urls)
Passkey support
A way for domains to actually trust that their content is handled properly on your client and their users are safe. This is why MCP moved off of dynamic client registration and onto CIMD, your client id is now a document you host on your own domain, which is just origins again.
A back button. Every page you land on, you can back out of. Agent actions are fire and forget.
Tabs (parallel sessions that are isolated from each other and that the user can actually see and switch between)
Incognito. The more agent memory features ship, the more you want a session with no state and no memory.
The padlock. There is one spot in the browser that tells you that you are really on stripe.com, and there is nothing like it when an agent calls a "stripe" tool.
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 launched in November 2024 doing three jobs: plugging local stuff into the agent (file system, git, sqlite), plugging remote services in (stripe, linear, your SaaS), and, a bit later, getting UI into the agent. Each of those has since gone somewhere else.

Local went to bash. Once agents had a shell, wrapping git in an MCP server made no sense when the model already knows git, and skills (a markdown file that explains a cli) finished the job.

Remote went to the api. Every company that stood up a remote MCP server eventually asked why it wasn't just part of their api. The July 2026 release dropped session ids, and what's left is stateless http with json schema and oauth, which is close to an OpenAPI extension.

UI went to the browser. MCP Apps is a sandboxed iframe talking to the host over postMessage, with the host holding the token.

The part of MCP that held up is the auth. Your client id is a metadata document on your domain (CIMD), the resource server points to its auth server at a .well-known url, and the auth server publishes its own metadata. Most of that is IETF work MCP made mandatory, and 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, and made Claude in Chrome generally available, letting Claude work across websites using the user's existing sessions.

OpenAI added a built-in browser to ChatGPT and Codex, where the user and the agent share the same browser, tabs, sessions, and logged-in state. Then, just a few weeks ago, OpenAI added WebMCP support directly into that browser, allowing ChatGPT to discover and call tools exposed by websites. Google is moving in the same direction. At I/O, the Chrome team described what they are building as the "agentic web," introduced WebMCP in Chrome, and said Gemini in Chrome will support it.

The interesting part is not that all these companies suddenly decided they love browsers. It is that once you try to give agents access to the real web - logged-in apps, tabs, permissions, navigation, user-visible state, and all the weird services that will never build an MCP server - you keep ending up back at the browser.

A year ago, the default assumption was that agents would replace it. Right now, it looks much more like it is becoming one of the agent's most important tools.

What the web needs next

The browser is already pretty close. But exposing tools is only the beginning. Once agents start doing real work, a few more things need to work too. Here is a non-complete list of the things that the browser needs to be a first party surface for agents:

WebMCP: The browser already runs the site's code and holds the user's session. We need a standard way for agents to use that functionality. That's what WebMCP adds: sites can expose JavaScript functions and HTML forms as structured tools for agents to discover and call. Search for a flight, update a cart, book an appointment, all through the website the user already uses. WebMCP is currently in an origin trial in Chrome, so you can start testing it on your own site now.
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. If I trust one agent to perform an action, that permission shouldn't automatically apply to every agent using my browser. The community has been discussing how to persist permissions for individual agents.
Tasks that survive navigation: A checkout might span shipping, billing, and confirmation pages. From the user's perspective, that's one task. The proposed continuation tokens would let a tool operation continue across pages on the same origin, so the agent doesn't have to reconstruct the flow every time the page changes.
A proper handoff to the human: Sometimes the site needs the user to answer a question, sign in, or approve something. The elicitation proposal explores how to request that input in local and remote browsing. And approval needs to mean a human actually approved. An agent clicking the page's “Approve” button itself doesn't give us that.
Agents talking to the site's agent: A website may already have an assistant that knows its products and how its business works. My agent should be able to ask that assistant for help. There is an open discussion about exposing site agents through tools, including requests that carry images and other richer inputs.
Letting the user choose the agent: We can end up with an assistant from the browser, another from an extension, and another from the site, all trying to help at once. The browser needs a way to coordinate them around the user's preferences. Agent negotiation is the community's discussion of that problem.

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.