What Is WebMCP, and Why Should Every Web Developer Care?
WebMCP lets websites expose structured tools to AI agents instead of forcing them to simulate clicks and typing. Here's how it works — and how Mermail uses it for email.
By Toan Nhu
AI agents can operate websites today by reading pages and simulating clicks, typing, and scrolling. That approach is fragile because the agent must interpret an interface built for people. Labels can be unclear, workflows can depend on hidden state, and small design changes can break an automation.
WebMCP proposes a more explicit relationship between websites and browser-based agents. A site can publish selected actions as structured tools so an agent can understand what the application supports, which inputs an action accepts, and how to invoke it.
From simulated clicks to structured tools
Conventional browser automation relies on actuation: examine the page, identify interface elements, and imitate a human. Every inferred step adds uncertainty.
With WebMCP, a website can expose a tool contract containing a unique tool name, a useful description, a JSON input schema, an execution function, and optional annotations such as whether an action is read-only.
An email product could expose capabilities such as searching messages, retrieving a message, opening a composer, replying, or moving mail. The agent can call a named function with structured input instead of hunting for the correct field and button.
How WebMCP works
The proposed standard creates a browser-native communication layer between a web application and a compatible agent.
1. The website registers tools
The application registers the actions it chooses to expose through the page's model context. Each registration describes the action, defines its accepted input, and connects it to application-owned code.
await document.modelContext.registerTool({
name: "search_messages",
description: "Find message metadata in the current mailbox.",
inputSchema: {
type: "object",
properties: { query: { type: "string" } },
required: ["query"]
},
execute: async ({ query }) => findMessages(query)
});The site retains control of authentication, authorization, validation, business rules, and execution.
2. The browser exposes relevant tools
The browser gathers tools registered by the active page and presents them to a WebMCP-aware agent. Since registration follows the page lifecycle, the available tool set can change with navigation and application state.
For example, a public product page might expose pricing data, while a signed-in mailbox might expose account-specific email actions. This produces a contextual capability surface rather than permanent access to every application feature.
3. The agent invokes a tool
When the user asks for an action, the agent selects a suitable tool and supplies schema-compliant arguments. The application validates and performs the operation, updates its interface, and returns a structured result.
Declarative and imperative WebMCP
WebMCP describes two ways to publish tools:
- Declarative: annotate ordinary HTML forms with tool names and descriptions. This can adapt existing form workflows with relatively little code.
- Imperative: register tools with JavaScript. This fits dynamic, stateful, context-sensitive operations that need custom validation and execution.
Mermail uses the imperative style because email actions depend on the current workspace, mailbox, permissions, validation rules, and confirmation state.
WebMCP and MCP solve different problems
WebMCP is not a replacement for the Model Context Protocol.
- MCP connects an AI application to services, backends, data sources, and workflows, without requiring a visible browser page.
- WebMCP lets an agent interact with capabilities exposed by the website currently open in the browser, inside that page's context.
The approaches can complement one another: a product may use MCP for direct service integration and WebMCP for browser-native interaction.
How Mermail supports WebMCP
Mermail treats WebMCP as a progressive enhancement. Controlled rollout modes can disable it, enable read-oriented capabilities only, or expose the approved full tool set. Browsers without WebMCP support continue to use the normal application.
Public pages
On public Mermail pages, agents may be able to check service status, retrieve current pricing, and find and focus the signup action.
Authenticated workspace
After authentication, tools can list mailboxes in the active workspace and open a selected mailbox. Results remain limited to the user's current workspace context.
Active mailbox
Inside a mailbox, contextual tools can support listing recent message metadata; searching and reading messages; opening and optionally prefilling a composer; sending, replying, and forwarding; marking messages read or unread; moving messages between folders or to trash; and permanently deleting mail already in trash.
Mailbox-specific tools exist only while the corresponding context is active. When the user leaves, obsolete registrations are removed and pending work can be cancelled.
Keeping the user in control
Email contains private data, third-party content, and potentially irreversible actions. A safe WebMCP implementation therefore needs more than a list of functions.
Strict input validation
Tool inputs are checked at runtime. A schema helps an agent construct requests, but the application must still treat incoming data as untrusted.
Bounded results
Read operations should return limited, relevant projections instead of oversized mailbox payloads. This reduces exposure and keeps agent context manageable.
Untrusted email content
Instructions found inside messages do not gain authority merely because an agent read them. Email content must be handled as untrusted input.
Visible confirmation
Outbound and destructive actions require confirmation in Mermail's interface. Sending, replying, forwarding, trashing, and permanently deleting messages cannot happen silently.
Context-aware access
Read-only and full-access capabilities are separated. Rollout controls enable deliberate, incremental access rather than an all-or-nothing switch.
Lifecycle management
Registrations follow the current page and component lifecycle. When the context changes, obsolete tools disappear and pending operations can be cancelled.
Operational visibility
Privacy-conscious registration and execution outcomes can be recorded to measure reliability, without letting analytics alter tool behavior.
What WebMCP means for email
Agents increasingly need to search for receipts, summarize conversations, organize mailboxes, draft replies, and send messages. These workflows should not depend solely on whether an agent correctly identifies a visual control.
WebMCP gives email applications a direct way to describe capabilities while retaining their own interface, permissions, validation, and confirmation rules. Users gain more predictable browser automation, while developers keep authority over which actions exist, when they are available, how they are validated, and which require human approval.
An early but important standard
WebMCP remains experimental and continues to evolve through browser implementation work and the Web Machine Learning Community Group. Developers should adopt it as a progressive enhancement with feature detection and controlled rollout.
Its broader direction is significant: the web already uses structured descriptions for browsers, search engines, and assistive technologies. Agents also need explicit contracts that explain what they can safely do.
The aim is not to remove people from the interface. It is to create applications that work well for users and for agents acting under their direction.
