WebMCP arrives in Chrome 149: preparing websites for agents securely

Chrome 149 is opening a WebMCP origin trial, testing a proposed API through which a web page declares structured actions for AI agents. Instead of studying a screenshot, interpreting the DOM and simulating a chain of clicks, an agent can discover a tool such as filter_results, run_diagnostics or start_application, together with a description and input schema.

The goal is not to replace human interfaces or backend MCP servers. WebMCP brings the agent closer to logic already running in the tab, with current state, user authentication and a visible interface. That reliability promise creates another action surface. A poorly designed function may expose data, cause an irreversible change or relay prompt injection. Experiments should start with narrow, reversible tasks.

The short answer

Why agents need a structured interface

A general-purpose agent often behaves like an approximate user. It observes a page, searches for the button that appears to match an intention, fills a field, waits for an update and repeats. Every step can fail after a label changes, a control moves, a modal appears or two commands look similar.

WebMCP lets the site declare what an action means. A schema distinguishes a first name from a full name, an ISO date from free text or a read operation from a state change. The function can then reuse client logic and update the interface in front of the user. The agent does not necessarily bypass the product experience.

This can reduce the number of steps and parameter hallucinations. It does not make the agent deterministic. The model still chooses a tool, collects values and interprets the result. The more overlapping tools a page exposes, the harder that choice becomes and the more context it consumes.

Chrome suggests structured forms, complex booking, routing to the correct support process and diagnostics hidden behind menus. The best first candidate is not the most spectacular action, but one where click automation is fragile and users can verify the outcome visually.

WebMCP is not backend MCP

MCP usually connects an AI client to a remote server or local process over a dedicated protocol. Such an integration can run without an open page and access an API, database or system tool. It often needs authentication and logic separate from the website.

WebMCP is a web-platform API inspired by the same tool and schema vocabulary. Code runs inside the page, follows its lifecycle and shares its state. The user retains the interface, session and ability to see what happened. The proposal targets collaborative workflows with a human in the loop, not an autonomous agent operating for hours in the background.

An organization may keep a backend MCP server for automation and add WebMCP to tasks depending on visual context or browser confirmation. One does not require abandoning the other. Teams must nevertheless document where authority lives: server, web client or both.

Minimal imperative registration

The current JavaScript API uses document.modelContext. Documentation says the former navigator.modelContext is deprecated in Chrome 150, so a new prototype should use the latest documented interface immediately.

const controller = new AbortController()

await document.modelContext.registerTool({
  name: 'prepare_support_request',
  description: 'Prepare a support request for the issue visible on this page.',
  inputSchema: {
    type: 'object',
    properties: {
      category: {
        type: 'string',
        enum: ['billing', 'access', 'technical']
      },
      summary: { type: 'string', maxLength: 500 }
    },
    required: ['category', 'summary']
  },
  annotations: {
    readOnlyHint: false,
    untrustedContentHint: true
  },
  async execute(input) {
    const values = validateSupportRequest(input)
    showSupportDraft(values)
    return { status: 'draft_ready' }
  }
}, { signal: controller.signal })

// Remove the tool when page state no longer permits it.
controller.abort()

This example prepares a visible draft rather than immediately submitting the request. Validation remains in application code even though the schema announces expected types and values. AbortSignal removes the tool when the user navigates, signs out or leaves the state in which the action is valid.

The schema is not a security boundary. Chrome recommends strict code validation and descriptive errors. A client or future implementation may provide unexpected input, and business rules evolve faster than descriptive declarations.

Declarative tools for forms

WebMCP also proposes a declarative form that annotates HTML. It fits an action already represented by fields and submission, allowing the browser to derive a tool without duplicating the complete structure in JavaScript.

The imperative form remains useful for navigation, dynamic state, composition across components or operations that are not simple form submissions. Both should retain semantic HTML. WebMCP is progressive enhancement, not a reason to make the interface inaccessible to people or unusable in other browsers.

The site must continue to work when the API is missing. Capability detection, ordinary buttons and useful errors remain the foundation. A critical commercial feature should not depend on an experimental origin trial.

Trying WebMCP in Chrome 149

For local development, Chrome documents the chrome://flags/#enable-webmcp-testing flag followed by a restart. For a pilot website, a team can enroll in the Chrome 149 origin trial and deploy its token under the normal origin-trial rules.

An origin trial is time limited and may include usage restrictions. It gathers API feedback before possible stabilization; it is not a promise of permanent availability. The test plan must cover token removal and site behavior when document.modelContext no longer exists.

Chrome also offers a tool-inspector extension. It displays active registrations, manually invokes functions, checks JSON Schema and shows outputs or errors. Its test conversations use a preview Gemini model by default; this component is separate from Gemini in Chrome features.

Test several phrasings of the same intention, missing values, excessive input, route changes and repeated calls. A unit test verifies function code. An agent evaluation verifies that the model selects that function at the right time.

Origins, iframes and Permissions Policy

WebMCP requires an origin-isolated document. If a site disables isolation, including through Origin-Agent-Cluster: ?0 and document.domain, the APIs are unavailable. This keeps the tool's associated origin stable throughout its lifetime.

The tools Permissions Policy defaults to self. A top-level page and same-origin frames can register tools, while a third-party iframe cannot do so automatically. To authorize an external frame, the page explicitly delegates capability, for example with allow="tools".

Delegation alone is insufficient. An imperative tool must also list secure origins in exposedTo, and the consumer must request tools from that origin. This two-sided decision reduces accidental cross-frame exposure.

Broad lists weaken the model. Name exact HTTPS origins, understand their administrators and avoid sharing actions containing personal data with a provider that does not need them. A read-only tool can still reveal history, favorites or customer identifiers.

Prompt injection remains the central risk

A page may display a notice, user comment, imported ticket or third-party description. If that text contains a malicious instruction aimed at the agent, the model may try to follow it as part of its mission. Sending the final call through a structured tool does not remove indirect prompt injection.

Chrome recommends untrustedContentHint when output contains external or user-generated data. readOnlyHint signals that a tool does not change state. These annotations help the agent apply guardrails and decide on confirmation, but they are not server authorization.

Every function must repeat conventional controls: session, role, resource ownership, CSRF protection where relevant, rate limits, business validation and logging. The application must never treat a WebMCP call as trustworthy merely because it came from the user's browser.

An irreversible operation needs explicit confirmation in an interface that page content cannot impersonate. Users should see the object, amount, recipient and exact effect. “The agent requested this” is not sufficient evidence of intent.

Design fewer, clearer tools

Chrome recommends one function per tool and non-overlapping roles. create_event means the event will be created; start_event_creation means only opening or preparing the flow. That distinction prevents an agent from choosing a final action while expecting a draft.

Names and descriptions should stay short. Preliminary guidance suggests 30 characters for tool and parameter names, 500 for a tool description, 150 for a parameter description and roughly 1,500 characters for one output. These budgets may change, but they show why full documentation should not enter context on every call.

Accept raw user data and normalize it in code rather than asking the model to perform unnecessary calculations. A range such as “11:00-15:00” can be interpreted by the function instead of converted into minutes by the agent. Types, enums and explicit errors reduce guesswork.

The tool should update the interface after success so the user and agent share the same observable state. For slow processing, a clear status and cancellation path are better than an early response claiming completion.

A responsible experiment plan

1. choose a frequent, narrow, reversible and verifiable task;
2. measure the existing click workflow before adding the tool;
3. keep the interface and semantic HTML fully functional;
4. give every tool an unambiguous verb and effect;
5. minimize parameters and validate all input in code;
6. register tools only when current page state supports them;
7. separate reading, preparation and irreversible action;
8. require human confirmation for sensitive effects;
9. test prompt injection, repeated calls, navigation and network failures;
10. plan trial removal and follow proposal changes.

Useful metrics extend beyond invocation rate. Compare end-to-end success, corrections, abandonment, canceled confirmations and permission incidents. A quickly called action that requires manual repair is not an improvement.

An experiment that may change the web contract

WebMCP proposes that websites stop forcing agents to guess every interface. An author-declared action can be more robust than a click chain while keeping users in a visible page. Complex forms and business tools have clear potential.

The project remains experimental, openly discussed and subject to change. Adoption should not start with payments, deletion or global administration. A small read-only tool or controlled draft can evaluate reliability without transferring too much authority. If WebMCP stabilizes, teams treating security, semantics and evaluation as one design problem will have the strongest foundation.