WebMCP: The missing bridge between AI agents and the web

Part of the ongoing MCP series. Read the previous piece: MCP Apps: SaaS Context Engines

The Problem with Browser Agents Today

If you've watched a browser-based AI agent complete a task — fill a form, navigate a dashboard, submit a request — you've noticed two things. First, it works. Second, it is painfully slow.

That's because today's browser agents operate by extraction and inference. They pull the raw HTML, clean it up, feed it to a large model, take a screenshot, annotate UI elements, and try to figure out which button to click next. For a model, reading a modern web page is like trying to understand a city by reading all of its building permits — technically possible, but full of noise, and prone to getting lost.

And it's not just slow. It's nondeterministic. The same agent, on the same page, might navigate successfully nine times and fail on the tenth because a minor design change shifted an element. For anything beyond a demo, this reliability gap is a blocker.

WebMCP is an attempt to fix this at the source.

What WebMCP Actually Is

WebMCP is a proposed web standard that lets web applications explicitly declare what they can do — in a form that AI agents can directly call, without needing to interpret the UI.

Instead of an agent scraping your DOM and guessing what "Add Item" does, your website tells it: here's a tool called add_item, here's what it needs as input, here's what it returns. The agent calls the tool. Your application runs it. Done.

Think of it as MCP — the Model Context Protocol that's already reshaping how agents interact with tools and services — but native to the browser. Rather than spinning up a separate MCP server, your website itself becomes the tool surface. Tools are declared inside the page, discovered when the agent visits, and executed in the browser context.

This removes a layer of infrastructure while adding a layer of reliability. No separate server to host and maintain. No need to re-implement your application logic somewhere else. Just your website, with additional metadata.

WebMCP is being co-developed by Google's Chrome team, Microsoft's Edge team, and Alex Nahas — who built the precursor (MCPB) while at Amazon. It's currently in W3C incubation, with browser support expected across Chrome and Edge by mid-to-late 2026.

How It Works in Practice

There are two ways to make your web application WebMCP-ready: declarative and imperative.

The declarative approach works by adding attributes to your HTML — particularly forms. If you already have a booking form or contact page, you annotate it directly:

<form tool-name="book_table" tool-description="Reserve a table at the restaurant">
 <input name="party_size" tool-param-description="Number of guests" />
 <input name="date" tool-param-description="Reservation date (YYYY-MM-DD)" />
</form>



That's it. WebMCP-capable agents that visit the page automatically discover this tool, infer the input schema from the form elements, and can call it programmatically. No JavaScript required. For static sites, legacy CMS pages, or any scenario where you just want to make existing forms agent-accessible, this is the path of least resistance.

The imperative approach gives you full control via JavaScript:

navigator.registerTool({
 name: 'add_item',
 description: 'Add a product to the shopping cart',
 inputSchema: {
   type: 'object',
   properties: {
     product_id: { type: 'string' },
     quantity: { type: 'number' }
   }
 },
 execute: async ({ product_id, quantity }) => {
   await cart.addItem(product_id, quantity);
   return { success: true, cart_total: cart.getTotal() };
 }
});



You register tools when relevant UI components mount, and unregister them when they unmount. This means the tools an agent sees change contextually as the agent navigates the application. On a search results page, it gets filter and sort tools. On a product page, add-to-cart. On a checkout page, address and payment tools.

The agent's available capabilities stay scoped and relevant at all times — not a flat dump of everything your app can ever do. This contextual loading is one of WebMCP's most underrated properties, and it maps naturally onto how well-designed component-based applications already think about state.

Speed and Reliability That Actually Matter

A concrete demonstration: a developer types "Add a new store called Drugstore. Add lip balm." Five seconds later, a new store is created and the item is added — through WebMCP tool calls.

Compare that to a conventional browser agent completing the same task: load page → screenshot → interpret UI → identify button → click → wait → screenshot again → find input → type → wait. You're looking at 30 to 60 seconds at minimum, with a meaningful failure rate.

For one-off tasks, this gap is tolerable. For workflows where agents are doing volume — processing batches of transactions, updating catalog entries, managing records across a dashboard — the difference is the line between a viable product and a proof-of-concept.

There's also a cost dimension. Browser agents that infer from screenshots or DOM dumps send far more tokens per action than agents that call structured tools. At scale, WebMCP's lean, schema-driven interaction model is meaningfully cheaper per operation.

Is WebMCP Just a Commerce Play? The B2B Case

It's easy to look at early demos — grocery apps, flight booking, restaurant reservations — and conclude this is primarily a consumer story. That undersells it considerably.

The most compelling B2B use cases are a natural fit:

• ‍Enterprise dashboards: Every SaaS company ships dashboards. Analytics platforms, CRM tools, project management applications, billing consoles — these are web-based, often accessed via SSO, and require users to learn increasingly complex interfaces. WebMCP lets an agent sit alongside a dashboard and translate intent into action. "Show me all accounts that renewed in Q1 and flag any with usage below 50%." That query-and-action loop is exactly what WebMCP enables.‍
• Internal tools: The origin story of WebMCP is an enterprise B2B problem. Alex Nahas built its precursor at Amazon to handle the fact that internal services were proliferating, each requiring its own MCP server, each with its own authentication challenge. The browser solved all of this — it already had SSO, session cookies, and RBAC-scoped access. WebMCP made those internal surfaces agent-accessible without rebuilding the auth layer from scratch.‍
• SaaS onboarding and operations: One of the underappreciated problems in B2B SaaS is the learning curve. Every new team member, every power user attempting something complex, burns time learning where things live in the UI. An agent that interprets natural language and executes through WebMCP tools turns that problem on its head — you express intent, the agent does the navigation.‍
• Finance and accounting workflows: Paste six transactions from a credit card statement; tell the agent to add and categorize them. Cross-reference a vendor list against an AP dashboard. Flag any unapproved invoice above a threshold. These are high-volume, context-rich, repetitive tasks that knowledge workers spend hours on every week.

The key insight: dashboards are the last bastion of the web. Social, entertainment, and news have largely moved to native apps. But dashboards remain web-based because they're the lowest-maintenance way to ship functionality across web, tablet, and desktop surfaces. They are everywhere — and they're precisely where WebMCP adds the most value.

MCP Servers vs WebMCP: A Decision Framework

If you're already thinking about AI-readiness for your product, you may have started with a traditional MCP server. WebMCP doesn't replace that — but understanding when each is the right tool matters.

Use a traditional MCP server when:

• ‍‍Your tools need to be invoked outside a browser context (e.g., from a CLI agent or desktop AI assistant)
• You're exposing server-side operations that don't map to a user session — batch jobs, backend data access, internal APIs
• You need to support a wide ecosystem of agent clients, some of which may not have browser capabilities
• You're building tools that agents load persistently, regardless of which webpage they're visiting

Use WebMCP when:

• You have a web application and want agents to interact with its existing interface
• You want to inherit browser-based authentication — SSO, session cookies, RBAC — without building a separate auth layer
• The operations you want to expose are already implemented in your frontend or accessible from the browser context
• You want context-sensitive tools that change based on where in the application the agent is operating
• Speed and reliability matter more than maximum cross-client ecosystem reach

The two approaches are not mutually exclusive. A product might use a traditional MCP server for headless, API-level operations — and WebMCP to let agents interact with its dashboard surface. This layered approach covers both the programmatic backend access pattern and the in-browser user-session pattern.

WebMCP currently focuses on tool calling. It does not include MCP's concept of resources or prompts, at least in the current draft. If your use case depends on agents accessing documents or structured data sources as resources, a traditional MCP server is still the right path there.

Where This Fits in the MCP Wave

We wrote recently about MCP Apps — the emerging pattern where AI hosts can render custom UI components from tools, turning agents into full application surfaces. WebMCP sits in a related but distinct part of this landscape.

Both are responses to the same underlying shift: AI agents are becoming primary consumers of software functionality, alongside human users. The question each product team has to answer is where the agent meets your product, and how you make that meeting reliable, efficient, and useful.

For consumer products and new experiences built around AI, MCP Apps make sense — you design the interaction surface for the agent from the ground up. For existing web applications, especially complex B2B tools with established UIs and user sessions, WebMCP is the lower-friction path. You're not redesigning the product for AI. You're extending what you already have.

The comparison that keeps coming up is responsive design. When mobile arrived, most teams didn't rebuild their web apps from scratch — they added responsive breakpoints and the site was mobile-ready. WebMCP offers a similar incremental path to agent-readiness: annotate your forms, register your key operations, and your web application can now be operated by an AI without re-architecting anything.

Where WebMCP Is Headed

This is an early standard. The W3C incubation process means the spec is still evolving, and early adopters should expect some flux. A polyfill is available today at docs.mcpb.ai, and Chromium supports the feature behind an experimental flag. Native browser support across Chrome and Edge is expected in the second half of 2026.

The security story is also still maturing. Any browser-based agent framework faces the question of cross-tab context isolation — an agent with access to your bank account tab and a malicious site tab should not be able to move data between them. WebMCP improves on raw DOM scraping by making interactions explicit and structured, but expect something analogous to CORS policies for tool access to emerge as the standard matures.

For product teams, the practical path forward is clear: identify the five to ten operations in your web application that are most frequently repeated, most likely to benefit from natural language interaction, or most likely to be called by an agent on behalf of a user. Register those as WebMCP tools. Test them with the Chrome inspector extension. Watch the interaction patterns.

The spec will evolve. The ecosystem will grow. But the applications that make themselves legible to agents early — that declare their capabilities rather than waiting for agents to infer them — will be the ones that compound their advantage as AI-driven workflows become the norm.

Further reading: docs.mcpb.ai · W3C WebMCP Community Group: web-machine-learning/webmcp · Chrome experimental flag: chrome://flags/#web-mcp