WebMCP Browser Tools for AI Agents

An inventory page already knows which filters are visible and which user is signed in. WebMCP proposes a structured way for a browser-mediated agent to invoke an action in that page, avoiding the need to infer every interaction from pixels or selectors.

Start with a narrow operation such as filtering visible records. Check that tool invocation preserves the application's permissions, including after the user's session or access changes.

The Web Machine Learning Community Group draft, dated October 16 and reviewed October 18, 2026, remains experimental work rather than a W3C Recommendation. WebMCP is also separate from backend MCP. Its browser APIs, document model, and implementation support need to be checked together.

Current imperative tools live under document.modelContext

The current draft registers an imperative tool with document.modelContext.registerTool(). A page supplies a name, human-readable description, input schema, and execution callback. This illustrative registration assumes the application already implements filterVisibleInventory; it is not a complete browser compatibility test:

await document.modelContext.registerTool({
  name: "filter-inventory",
  description: "Filter the visible inventory by approved query fields",
  inputSchema: {
    type: "object",
    properties: {
      status: { type: "string", enum: ["available", "assigned"] }
    },
    required: ["status"]
  },
  async execute({ status }) {
    return filterVisibleInventory(status);
  }
});

The browser can expose registered tools to an eligible agent. The agent discovers the tool and its schema, requests an invocation with structured arguments, and receives the callback result through the browser. The page remains responsible for its code and server requests.

The proposal also explores declarative tools derived from HTML forms. Imperative registration is the relevant current replacement for older context APIs, while declarative behavior continues to develop in the Community Group.

Tool lifetime follows the document and registration controls. A page can add tools when a particular UI state becomes available and remove them when that state ends. That is useful for authenticated or multi-step applications because the active tool set can match the visible page rather than a permanent external manifest.

Dynamic registration introduces a review requirement: authorization cannot depend on whether a tool happens to be present. A user who loses access after the page loads must also lose access at the application server. Test a stale page that still displays the tool after tenant membership is removed. The invocation should fail authorization even though registration originally succeeded.

provideContext and clearContext were removed in March 2026

Earlier WebMCP material used navigator.modelContext.provideContext() and clearContext(). Do not use provideContext() in new integrations.

The March 5, 2026 Community Group minutes record a resolution to drop both methods from the specification. The group had discussed how provideContext() could overwrite previously registered tools in the same environment, then agreed to focus the draft on tool registration. The corresponding change landed in the repository.

The current draft uses document.modelContext.registerTool(), although prototype browser builds may expose a different revision. Feature detection can preserve the ordinary UI when support is absent; it cannot establish conformance to the draft by itself. Adding a compatibility wrapper around removed navigator methods would preserve an abandoned proposal surface and make future migration harder. A checker should identify the current draft method and state that browser support remains experimental.

Permissions Policy controls where the API is available

The current draft defines a policy-controlled feature named tools with a default allowlist of self. Top-level documents and same-origin frames receive the default behavior. A cross-origin iframe requires explicit delegation, for example:

<iframe src="https://agent-ui.example" allow="tools"></iframe>

An origin can disable access with a Permissions Policy response field such as tools=(). When policy blocks the feature, imperative registration rejects with NotAllowedError.

Permissions Policy governs API availability in a document tree. It doesn't grant an agent application permission to modify data, and it doesn't validate the business meaning of a tool call. Likewise, same-origin status says which documents share an origin; it doesn't establish that a requested mutation is appropriate for the current user.

The October 16 draft includes exposedTo registration options for selected origins and fromOrigins when discovering tools. These remain draft APIs. Define the permitted origins in application policy, show the receiving origin and test nested frames, navigation and policy changes.

Browser mediation can provide a common point for discovering tools, validating supported schema behavior, routing invocations, enforcing document lifetime, and presenting user controls. The draft specification still contains open questions about validation, agent access, prompting, and cross-document behavior, so product authorization must not wait for the browser design to settle.

Human oversight is part of the proposed use case

The repository describes browser workflows with human oversight and lists fully autonomous operation without a browser UI as a non-goal. A useful implementation keeps the resulting action visible in the page.

Visibility should survive navigation and partial failure. If a tool starts a multi-step change, the page should show pending state, completed state, and any compensation the user may need to perform.

For a low-impact filter, immediate execution may be reasonable. For sending a message, purchasing, changing access, deleting data, or exporting sensitive records, the user should see the exact proposed action near the point of commitment. Confirmation needs to identify the origin, target object, important parameters, and consequence.

Do not rely on the tool description as a security statement. A page controls both the description and callback, and compromised page content can include manipulative instructions. The agent should treat names, descriptions, arguments, and results as untrusted content. The application must validate inputs again and enforce current user authorization on the server.

Narrow tools are easier to govern. Prefer archive-report(reportId) with a server-side ownership check over request(url, method, body). Avoid generic script execution, arbitrary navigation, unrestricted selectors, raw credential access, and callbacks that accept internal network destinations.

Tool results can expose sensitive data or carry hostile instructions into the agent. Return only the fields needed for the workflow, label untrusted user content, cap result size, and keep secrets out of descriptions and outputs. Rate limits and idempotency protect both accidental repetition and hostile invocation.

Operational telemetry should record the page origin, tool name, authenticated account, authorization result, confirmation result, and high-level outcome. It should not record tokens or sensitive payloads by default. Users need a way to stop an in-progress operation and inspect what changed.

Compare the tool with the ordinary browser action

Choose a task where structured invocation helps the user. Run it through the normal UI and through the proposed tool, then compare the resulting state and permissions.

Repeat after logout, a tenant-access change, navigation and a refused confirmation. Check cancellation separately: the draft's registration signal can unregister a tool, while execution cancellation must also be handled by the callback and any downstream work. Removing a tool does not undo a completed change.

Keep the ordinary interface available when the browser lacks support. Evaluate wider exposure only after the narrow workflow, origin policy and failure states work in the browser versions you intend to support.