Alex Nahas built MCP inside a browser at Amazon. Now Microsoft and Google are turning it into a W3C standard.
This article is adapted from Alex’s interview in our video series MCP MVP.
Episode 1 features Alex Nahas, creator of MCP-B and a driving force behind the WebMCP specification.
Have thoughts on WebMCP? Share your thoughts in the video comments above ↑
Imagine your website telling a visitor’s ChatGPT agent, "Here's what I can do. Here's how to ask me to do it."
Until February 10, 2026, there were only two ways for an AI agent to interact with a website:
- Visually The agent evaluates screenshots, reading text and inferring where to move a cursor on a screen.
- Semantically The agent parses reams of underlying XML (DOM, accessibility tree) to extract data and call events on elements.
These can be performed at the browser level or systematically, with the agent controlling the computer system, synthesizing inputs. These require extra roundtrips, inference, and multimodal models, impacting performance, cost, and reliability, gobbling up tokens and time while agents fumble around on for themselves.
WebMCP seeks to be an efficient, reliable third option. Sites can expose structured tools as JavaScript functions with descriptions and schemas that agents can call directly. It's currently being incubated by the W3C Web Machine Learning Community Group and has just dropped on Chrome.
If you're a web developer, WebMCP is worth your attention. It might change what "building a website" means.
The Amazon origin story
Alex Nahas was a backend engineer at Amazon when MCP hit in early 2025. Amazon, with its thousands of internal services, spun up what amounted to one enormous MCP server, providing thousands of tools, all crammed into a single context window.
"You had to disable them with process commands in the connection string," Alex explained. It was, charitably, a mess.
But the real problem was authorization. The MCP spec had adopted OAuth 2.1, which essentially nobody at Amazon had implemented internally. Every internal service had its own authentication story, and none of them spoke OAuth 2.1.
At Amazon, all authorization is managed through a federated browser experience that signs users into every service, dashboard, and resource available to Amazon employees. Alex had the idea to run MCP in the browser and leverage its SSO, session cookies, and existing identity providers.
That's what MCP-B is (the “B” stands for “browser”). Alex integrated the MCP TypeScript SDK into a client-side JavaScript application and built a custom transport using postMessage to communicate with a Chrome extension. And it worked too well to remain inside Amazon.
From side project to W3C standard
Teams from Google’s Chrome and Microsoft’s Edge had been working on parallel ideas. Chrome was prototyping “script tools,” and Edge was circling the same question: how do we let agents interact with web applications in a structured way?
When MCP-B arrived, they teamed up with Alex via the W3C and called it WebMCP.
But the name might be misleading: WebMCP is not MCP. It doesn't follow the JSON-RPC spec. Alex pushed early on to port the full MCP protocol to the browser, but the working group didn't want to couple too tightly to the spec. It shares MCP's API surface and conceptual model, tools with schemas that agents can call.
It’s designed specifically for the browser. It runs entirely client-side, lacking the client-server dynamic of Anthropic’s MCP, in which providers host MCP servers and agents consume via MCP clients. In this case, the web page is the “server” that starts when an agent lands on it. The same functions used to submit forms or query databases in React components can now be surfaced directly to agents, bypassing the need for them to synthesize click events and text input.
If you're thinking “Java and JavaScript” right now, you're not alone. The naming will create confusion, as WebMCP currently has no plans to implement prompts or resources, just the “tools” part of the MCP standard. Thankfully, Alex has created a polyfill that implements the WebMCP API and converts it to JSON-RPC, so you get a spec-compliant MCP SDK running in your browser.
The lethal trifecta
There's an unsolved security problem facing agents accessing the web: the lethal trifecta.
Picture this: you have two tabs open. Tab A is your bank. Tab B is a malicious site. A browser agent sits in the middle with context from both. This agent treats both sources of context as equal.
The malicious tab could tell the agent to extract routing numbers from the banking tab. Or push instructions in the other direction and have the agent wire funds. This isn't theoretical; it's architecturally inevitable with how browser agents work today. As Alex put it, "If you're going to use Comet, if you're going to use Atlas, you just have to say, okay, this is a risk I'm willing to take."
WebMCP doesn't eliminate this problem, but it meaningfully reduces the attack surface. Instead of the agent operating on screenshots and raw DOM, where it can see everything, including hidden elements, it operates on explicit tool calls. Discrete actions. Things the website has specifically chosen to expose. You can hash tools, set up elicitation flows for first connections, and scope trust to specific domains with a TTL.
Is it airtight? No. Prompt injection still exists wherever you have dynamic third-party tools. But going from "the model can see and do anything a user can, plus read the DOM" to "the model can call these specific functions" is a significant narrowing of scope that might change how browsers are built in the future.
Three WebMCP tool patterns
Alex has built a number of WebMCP-enabled sites, and he’s found that WebMCP tools fall into the following categories:
Read-only tools should be surfaced as a flat list, always available in the agent's context. These are your GET operations: fetching data, reading state. You don't want the agent navigating through your UI just to read information. Surface everything; let the agent query what they need.
Navigation tools are the system prompt of your website. They tell the agent what your site does and where information lives. "Here are the links. More tools will be disclosed as you visit them." It's the blueprint. You mark these as destructive because they cause visible changes—the page actually navigates, and an agent that respects destructive hints will flag that for the user.
Write tools take action. They fill out forms, submit data, make changes. Here's where MCP elicitation shines: the agent can fill out a form, then surface it to the user—"Here's what I'm about to submit. Yes or no?" The human stays in the loop.
With these three primitives, Alex argues, even an old WordPress site becomes "basically an AI company." Everything can be vanilla JavaScript, no framework required.
Why the web isn't going anywhere
Alex doesn’t believe that MCP and Agents will replace the web.
Consider the use cases: many applications provide more than just text, canvases (Figma) and complex dashboards (Quickbooks, Shopify) require a visual interface where the human is the primary actor and an agent would assist from the side. Other applications use data lookups and perform simple transactions, which are better served by bringing the application to the agent. WebMCP serves the first camp: the agent comes to the website, not the other way around.
Regardless of how people browse the web in the future, HTML, CSS and JavaScript will remain the core building blocks for universally compatible applications that every platform can render. The interaction model may shift from browsers to agents for many users and use cases, but the underlying substrate isn't going anywhere.
WebMCP is a progressive enhancement for the Web that enables websites to serve humans and agents. Websites persist. Agents need a better way to interact with them. A web standard is the right vehicle for that.
We’re early
WebMCP is early. The spec is transitioning from community incubation to a formal draft. Chrome has an experimental implementation behind a flag in Chromium. Alex expects official browser announcements by mid-to-late 2026.
If you want to try it now:
- The polyfill: Install @mcp-b/global and register tools with navigator.modelContext.registerTool(). It works with any frontend tool-calling framework—CopilotKit, AGUI, SystintUI.
- The Chrome DevTools fork: Alex maintains a fork of the Chrome DevTools MCP server that lets you call WebMCP tools, which means Claude Code can write and test its own WebMCP tools.
- The standard: Follow the work at github.com/webmachinelearning/webmcp. The chair, Ningxin Hu, is welcoming to newcomers.
- Docs: docs.mcp-b.ai has the full documentation for the polyfill and reference implementation.
What this means for you
If you build web applications, WebMCP is worth a look because it lets you define how agents interact with your site instead of leaving it up to the agent to figure out. It’s a proactive, progressive enhancement, much like adding accessibility features to your site.
You don't need to re-architect anything. The whole point is that you're wrapping existing client-side logic. Your add-to-cart() function, your search, and your form submission already work. WebMCP just makes them discoverable and callable by agents.
Whether this becomes the standard or a waypoint toward something else, the direction is clear: site owners who want to attract users operating through agents like Claude and ChatGPT will want an agent-facing layer to provide a best-in-class experience.
WebMCP is the most serious attempt at making that a platform primitive rather than an afterthought.
MCP MVP is a video series from Arcade spotlighting the builders shaping the agentic ecosystem. Watch the full video →
RL Nabors is a developer experience leader and alumni of the React team and W3C. They write about the agentic web at agenticweb.nearestnabors.com.
WebMCP brings MCP to the browser. Arcade is the runtime that brings MCP to production. Try for free →
