Google is making a significant bet that the future of web browsing will be shaped not just by human users clicking through pages, but by AI agents acting on their behalf. The company has introduced two new experimental proposals — WebMCP and the Extensions Proposal Protocol (EPP) — that aim to give AI models a structured way to interact with web content and browser extensions. If adopted broadly, these protocols could fundamentally reshape how software agents discover, understand, and act on information across the open web.
The announcements, detailed on the Chrome for Developers blog, arrive at a moment when the AI industry is grappling with a core technical problem: large language models are powerful reasoners, but they remain clumsy when it comes to taking action on websites. Current approaches often rely on screen-scraping, pixel-level interpretation, or brittle automation scripts. Google’s proposals represent an attempt to create a more principled infrastructure layer — one where websites and extensions explicitly declare what actions an AI agent can perform, much like APIs do for traditional software.
What WebMCP Actually Does — And Why It Matters
WebMCP, short for Web Model Context Protocol, is an open proposal that allows websites to expose structured tool definitions directly in their HTML. The concept builds on Anthropic’s Model Context Protocol (MCP), which has gained traction as a standard for connecting AI models to external tools and data sources. But where MCP typically operates server-side — requiring developers to stand up dedicated servers that AI clients can connect to — WebMCP brings this capability to the client side, embedding it in the fabric of web pages themselves.
In practical terms, a website owner could add a small block of structured metadata to their page declaring available actions. An airline’s booking page, for instance, might expose a tool called searchFlights with parameters for origin, destination, and date. An AI agent operating within the browser could then discover this tool, understand its inputs and outputs, and invoke it on behalf of the user — all without needing to visually parse the page or simulate mouse clicks. According to the Chrome for Developers blog, this approach is designed to be “web-native,” meaning it respects existing web standards and works within the browser’s security model rather than circumventing it.
The Extensions Proposal Protocol: A Parallel Track for Browser Add-Ons
Running alongside WebMCP is the Extensions Proposal Protocol, or EPP, which applies a similar philosophy to Chrome extensions. Today, browser extensions operate largely as black boxes from the perspective of AI agents. An extension might offer powerful capabilities — managing passwords, organizing tabs, translating text — but there is no standardized way for an AI model to discover or invoke those capabilities programmatically.
EPP changes this by allowing extension developers to declare their available tools in a structured format that AI agents can read and act on. The protocol defines a manifest-like declaration where extensions list their capabilities, input schemas, and expected outputs. This means an AI assistant integrated into Chrome could, in theory, look at the user’s installed extensions, determine which ones are relevant to a given task, and orchestrate them together — all with the user’s explicit permission. The Chrome for Developers blog emphasizes that user consent and control remain central to the design. No action would be taken without the user approving it, and the browser itself acts as a mediator between the AI agent and the extension.
The Broader Industry Context: A Race to Define Agent Infrastructure
Google’s proposals do not exist in a vacuum. The past year has seen an accelerating race among major technology companies to define how AI agents interact with the digital world. Anthropic’s MCP has emerged as an early front-runner in the server-side tool-calling space, with adoption from companies including Block, Replit, and Sourcegraph. OpenAI has pursued its own approach through function calling and plugin architectures. Microsoft has invested heavily in agent capabilities within Copilot and its broader Azure AI platform.
What distinguishes Google’s approach is its focus on the browser as the primary surface for agent activity. This makes strategic sense: Chrome commands roughly 65% of the global browser market, according to StatCounter data. By embedding agent protocols directly into the browser and its extension system, Google positions Chrome not merely as a window to the web but as an active intermediary between users, AI models, and web services. The company is effectively arguing that the browser — not a standalone app or a cloud API — should be the operating environment where AI agents do their work.
Technical Architecture: How the Pieces Fit Together
The technical design of WebMCP reflects a deliberate effort to stay compatible with existing web standards. Tool definitions are expressed using JSON-LD or similar structured data formats that can be embedded in a page’s HTML. This is conceptually similar to how Schema.org markup already allows websites to declare structured information about their content for search engines. The difference is that WebMCP declarations describe actions, not just data.
On the browser side, Chrome would include a discovery mechanism that scans pages for WebMCP declarations and presents them to any authorized AI agent running in the browser context. The agent could be a built-in feature of Chrome, a third-party extension, or an external AI service communicating through a defined interface. The Chrome for Developers blog notes that the team is exploring how to handle authentication, rate limiting, and abuse prevention — all critical concerns when exposing website functionality to automated systems. The design also contemplates a permissions model where users can grant or revoke an agent’s ability to use specific tools on specific sites, mirroring the permission prompts already familiar from features like location access and camera use.
What Website Owners and Extension Developers Should Watch For
For web developers, the immediate practical implication is that there may soon be a strong incentive to add WebMCP declarations to their sites. Just as Schema.org markup became a de facto requirement for competitive search engine visibility, WebMCP declarations could become important for ensuring that a site’s services are discoverable and usable by AI agents. Early adopters may gain an advantage as AI-assisted browsing becomes more common. The protocol is still in the proposal stage, and Google has invited feedback from the developer community through its public GitHub repositories and standards discussions.
Extension developers face a similar calculus. Those who adopt EPP early will make their extensions compatible with AI agent workflows, potentially increasing their utility and install base. The protocol also opens up new design possibilities: extensions could be built specifically as tool providers for AI agents, offering specialized capabilities — database lookups, API integrations, domain-specific calculations — that models can call on demand. This represents a meaningful expansion of what browser extensions can be and do.
Security, Privacy, and the Question of Control
Any proposal that gives AI agents the ability to take actions on websites raises immediate security and privacy concerns. The history of browser automation is littered with examples of abuse, from credential-stuffing attacks to click fraud. Google appears to be aware of these risks. The WebMCP and EPP proposals both emphasize that actions require explicit user authorization, that the browser mediates all interactions, and that websites retain the ability to control what they expose.
Still, difficult questions remain. How will websites distinguish between legitimate AI agent requests and malicious automated traffic? What happens when an AI agent misinterprets a tool definition and takes an unintended action — say, booking a flight the user didn’t actually want? Who bears liability in such cases? These are not merely theoretical concerns; they are the kinds of practical issues that will determine whether WebMCP and EPP gain real-world adoption or remain interesting but unused specifications. The proposals acknowledge these open questions and position them as areas for ongoing community discussion and iteration.
The Stakes for the Open Web
Perhaps the most consequential aspect of Google’s proposals is what they imply about the future structure of the web itself. For three decades, the web has been built primarily for human consumption — pages designed to be read, forms designed to be filled out by hand, interfaces designed for eyes and fingers. WebMCP and EPP represent a recognition that a growing share of web interactions may soon be conducted by software agents acting as proxies for human users.
If these protocols succeed, they could help preserve the open web’s relevance in an AI-dominated future. Without standardized ways for agents to interact with websites, there is a risk that AI companies will route activity through proprietary APIs and walled-garden platforms, bypassing the open web entirely. By offering an open, browser-based alternative, Google is making a case — self-interested, certainly, but also substantive — that the web should remain the primary venue for digital interaction, even when the entity doing the interacting is a machine. Whether the rest of the industry agrees, and whether website owners and developers choose to participate, will determine whether this vision becomes reality or remains an ambitious blueprint.
WebProNews is an iEntry Publication