WebMCP Browser Tools for AI Agents

WebMCP lets a web page expose structured actions to an agent operating through a browser. The page can reuse its current UI state, authenticated session, and application code while the browser brokers discovery and invocation.

This is Web Machine Learning Community Group draft work. It is not a published W3C Recommendation and it isn't the backend Model Context Protocol. Its API and security model are still changing.

That maturity label matters for readiness checks. Guidance based on an older explainer can recommend methods the Community Group has already removed.

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:

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.

provideContext and clearContext were removed in March 2026

Earlier WebMCP material used navigator.modelContext.provideContext() and clearContext(). A supplied readiness recommendation may still point to provideContext(). That advice is obsolete.

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.

Current page examples call document.modelContext.registerTool(). 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 draft is also exploring selective exposure to author-provided agents in frames. Treat those mechanisms as provisional. Cross-origin exposure needs an allowlist controlled by the application, clear display of the receiving origin, and tests for 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.

TKOResearch has no WebMCP tool to register today

The current TKOResearch site publishes information and accepts contact submissions. Wrapping contact submission in a browser tool would add a new invocation path for a workflow already served by an accessible form, without a defined user benefit or agent-specific authorization model.

No WebMCP code or endpoint should be added merely to satisfy a readiness scanner. A missing optional draft feature on an informational site is not a defect.

A future TARE interface could justify WebMCP for a precise, user-visible operation that benefits from structured browser actuation. Each tool would need a product owner, restricted schema, server-side authorization, confirmation rule, origin and frame policy, result minimization, telemetry, revocation, browser compatibility plan, and assessment against the current Community Group draft.

The adoption decision should follow that workflow. It should not begin with obsolete provideContext() syntax or an empty tool registry.