WebMCP could make browser agents less clumsy. It also makes permission design unavoidable.

Chrome is testing WebMCP, a proposed browser standard that lets a website expose selected functions as structured tools for AI agents. Instead of an agent trying to recognise buttons, fill forms and survive whatever a web page throws at it that day, the site can declare: here is an action I support, here are the inputs it accepts, and here is the result it returns. Chrome’s documentation describes WebMCP as a way to expose JavaScript functions and annotate forms so agents can interact with a page through a defined interface rather than by guessing at the UI. It is currently an early-stage experiment, running as a Chrome origin trial with a long way to go before it could be called a finished, broadly deployed standard. Chrome’s WebMCP documentation

The web has been asking agents to imitate people

Most browser-agent systems work from a mix of screenshots, accessibility information, page structure and browser automation. They may inspect the DOM, identify a target, click it, enter text and interpret the next page state. This is a reasonable workaround for a web built for human eyes and hands. It is also an awkward technical contract.

A site redesign can break selectors. A date-picker can behave differently from one site to another. A consent banner, login redirect, account-specific message or A/B test can send the agent down a path that its developer did not anticipate. The agent may still complete the job, but each step involves interpretation of a user interface that was never designed as a reliable tool API.

WebMCP offers another route. A page can register a named tool, describe what it does in natural language, define its input fields with JSON Schema and connect the call to its existing JavaScript. The draft specification centres on a document.modelContext API, including methods for registering tools, discovering them and executing them. The WebMCP draft specification

A simplified travel-search example might look like this:

await document.modelContext.registerTool({
  name: "search-flights",
  description: "Find available flights for the supplied journey.",
  inputSchema: {
    type: "object",
    properties: {
      origin: { type: "string" },
      destination: { type: "string" },
      departureDate: { type: "string", format: "date" },
      passengers: { type: "integer", minimum: 1 }
    },
    required: ["origin", "destination", "departureDate"]
  },
  async execute(criteria) {
    return searchFlightsInCurrentSession(criteria);
  }
});

The important part is not the syntax. The site has stopped asking the agent to infer how the interface works. It has supplied an explicit action and constrained the expected inputs.

That could reduce the cost and failure rate of browser automation. It might also improve observability: the application can record that an agent called search-flights with a particular set of arguments, rather than trying to reconstruct intent from a trail of clicks and keystrokes.

None of this gives the model better judgment. It gives it a cleaner way to act once it has made a decision.

WebMCP is not simply MCP in a browser

The name invites a useful but misleading shortcut: WebMCP sounds like every web page is about to become an MCP server.

The relationship is closer than coincidence. Model Context Protocol, or MCP, has made the idea of structured tools familiar: an AI client discovers a tool, learns what arguments it expects, calls it and receives a result. Most deployed MCP integrations use a backend service or dedicated MCP server. The service owns the API connection, authentication model, execution and often the system’s durable state.

WebMCP is aimed at a different boundary. Its tools are attached to the currently open page and execute in the browser context. That means they can work with the active session, current view and client-side application logic. The user may remain present in the tab while the agent works.

The WebMCP project explicitly positions the work as complementary to backend protocols such as MCP, rather than a replacement for them. The WebMCP repository and explainer

That is more than a technical distinction. A CRM, accounting platform or source-control system will often still need a server-side integration for work that runs outside a browser tab, spans users or requires durable service credentials. A rich web application may benefit from WebMCP when the task depends on what the signed-in user is already seeing and doing.

I would avoid treating the two models as interchangeable in product planning. A browser tool contract can improve an agent’s interaction with a page. It does not automatically provide the authentication, tenant separation, change management, logging or long-running execution model a production integration needs.

A clean action interface can magnify bad permissions

WebMCP’s practical value and its security concern are the same thing: it reduces the friction between an agent’s decision and an application action.

A poorly controlled browser agent might fail to locate a “Delete account” button. A well-integrated agent with access to a clearly named delete-account tool has no such mechanical handicap. That is excellent when the user explicitly wants the account deleted and the system verifies that instruction. It is far less comforting when the agent has absorbed hostile instructions from a document, webpage, email or search result.

Prompt injection does not disappear because a tool has a JSON schema. The injection risk changes shape. Instead of persuading an agent to click the wrong button, untrusted content may try to persuade it to invoke a legitimate tool with harmful arguments.

The draft includes hints such as readOnlyHint, for tools that do not change state, and untrustedContentHint, for output that should be treated as untrusted. Those are useful pieces of information for an agent client. They are not access control. The same applies to a tool description: it may help a model choose the right function, but it cannot determine whether the function should be available or whether a specific request is authorised. The WebMCP specification describes these annotations and the tool model.

A sensible WebMCP deployment needs the usual application security controls, with a few agent-specific additions:

• Keep the first release narrow: search, filtering, status checks, previews, calculations, draft generation and reversible edits are better candidates than payments, publishing or deletion.
• Validate every input in application code. A schema improves the interface; it does not replace business-rule validation.
• Enforce authorisation on the server after the browser-side tool is called. The fact that a user is signed in does not make every request from an agent acceptable.
• Require explicit human approval for consequential actions, especially payments, external messages, access changes, data exports, account deletion and production deployment.
• Record the tool name, arguments, initiating user, agent identity, approval event, outcome and resulting state change in logs suitable for investigation.
• Treat page content, document text and tool output as data. Do not allow a model to interpret untrusted content as authority to act.
• Keep descriptions factual and narrow. A tool called publish-post with a cheerful one-line description is not a safety system.

There is an awkward but healthy implication here: companies cannot claim that their agent is “just helping with the website” once they expose high-value actions as tools. They have made a decision about delegated authority. Their incident response, audit and user-consent design need to reflect it.

The browser is part of the control plane

The proposal uses existing browser security concepts rather than pretending an agent session is a separate universe. Chrome’s implementation applies origin isolation: WebMCP is only available in origin-isolated documents. The default Permissions Policy restricts tool use to the same origin; a cross-origin iframe needs explicit delegation through its allow attribute. Chrome’s implementation and security notes

For a non-browser specialist, the practical translation is simple: a page should not casually expose agent tools across embedded third-party content. The browser can limit which document gets to register or access tools. That is valuable containment for pages with advertisements, widgets, identity flows, payment components and other iframe-heavy dependencies.

It is still only containment.

The browser can answer, “Which page is permitted to offer this tool?” It cannot answer, “Should an AI agent be allowed to approve a €25,000 supplier payment from this user’s account?” That decision belongs in the product’s permissions, transaction controls, approval workflow and backend authorisation checks.

This is why I would be cautious about vendor claims that WebMCP will make browser agents safe by design. It can make the action interface clearer and more inspectable. Safety depends on the capability exposed, the authority behind it and the controls that remain in force when the tool is invoked.

What exists today is a promising experiment

WebMCP is proposed, not settled. Chrome’s documentation describes local development behind a browser flag and an origin trial beginning with Chrome 149. It also frames the work around local, human-in-the-loop browser workflows rather than invisible, autonomous operation at scale. Chrome’s WebMCP documentation

The public specification is also still developing. Its active work includes questions around output schemas, validation, progress reporting, multimodal values and user confirmation or elicitation. The declarative HTML form approach remains less complete than the JavaScript-based tool-registration path. The draft specificationThe WebMCP repository

That does not make WebMCP trivial or irrelevant. It means buyers and builders should distinguish three things that marketing will tend to merge:

• A browser can experimentally expose a structured tool.
• An agent can correctly choose and call that tool in a particular workflow.
• An organisation can safely operate that capability across users, browsers, edge cases, hostile content and incident investigations.

Only the first is meaningfully covered by the presence of an API.

For builders, the right early test is modest: choose one visible, low-consequence workflow that currently breaks under browser automation. Expose a narrow tool with strict parameters. Keep the standard interface available. Log every call. Test failure states and malicious instructions before celebrating the happy path.

For buyers, “supports WebMCP” is only the opening question. Ask which tools are exposed, what they can change, whether server-side authorisation is rechecked, how approvals work, what is logged and which browser-agent combinations have actually been tested.

WebMCP could save agents from spending their working lives pretending to be a person hunting for a button. The more successful it becomes at that job, the less excuse organisations have for treating delegated authority as an implementation detail.