An agent can click a checkout button by reading the screen. WebMCP offers another path: the website can expose a named checkout action with a schema and an expected result. That clarity also creates a new security interface.
WebMCP is an experimental web standard for letting a page publish structured tools to an AI agent running in the browser. A site can expose JavaScript functions or HTML forms as discoverable actions instead of making the agent infer every operation from pixels, labels, and page structure.
OpenAI now supports site tools in the ChatGPT in-app browser when the account, model, and page support the feature. This is early infrastructure, not a universal browser capability or a finalized W3C standard.
WebMCP gives the website a tool contract
A normal browser agent looks at a page and decides what to click, type, or submit. WebMCP lets the page say, in effect, “these are the operations I intentionally support.” Each tool can have a name, description, input schema, and handler.
The WebMCP repository describes two exposure styles. Imperative tools are registered through JavaScript. Declarative tools can be attached to forms, allowing an existing page interaction to become agent-discoverable without rebuilding it as a separate API.
| Method | Best fit | Main review question |
|---|---|---|
| Imperative JavaScript tool | Dynamic actions, custom validation, or stateful workflows | Can the handler enforce authorization and cancellation? |
| Declarative form tool | Existing form submissions with clear fields | Does the agent see the same validation and confirmation as a person? |
This complements backend MCP rather than replacing it
Backend MCP and OpenAPI integrations connect an agent to services outside the page. WebMCP is client-side. It gives the current website a structured way to expose actions within the browser context.
That can reduce duplicate work. A product team may already have validation, session state, localization, accessibility, and confirmation flows in its web application. Exposing the page’s intended action can be safer than asking an agent to reverse-engineer the interface.
It can also be weaker than a mature backend API if the page relies on hidden UI state or trusts the tool call too much. The server must still authenticate the user, authorize the operation, validate every field, and reject stale or replayed requests.
Every description becomes security-sensitive
A tool description is not documentation for humans alone. It helps the model decide when to call the tool. A vague description can route the agent toward the wrong operation, while an overbroad schema can expose parameters the user never intended to delegate.
- Name the action by its real effect, not a friendly marketing label.
- Use the narrowest input schema that can complete the task.
- Keep authorization on the server.
- Require confirmation for payments, messages, publishing, deletion, or account changes.
- Return a result that distinguishes success, rejection, cancellation, and partial completion.
This is the browser version of the issue in our cross-session agent messaging guide. A structured handoff improves reliability, but it also makes the handoff part of the permission boundary.
The specification expects a person in the loop
The current specification targets human-in-the-loop workflows and lists fully autonomous, interface-free operation as a non-goal. That boundary is sensible. A browser session contains identity, cookies, account state, and sometimes access to expensive or irreversible actions.
Human supervision should be more than a generic “allow” button. The confirmation needs to show the action, destination, important fields, price or scope, and what will happen next. A person cannot meaningfully approve a tool call if the interface hides its real effect.
Same-origin rules are only one layer
Origin exposure and permissions policy help control which contexts can publish tools. They do not solve business authorization. A tool exposed by the correct origin can still be too powerful for the current user, account, tenant, or page state.
Dynamic registration deserves particular attention. If a page adds and removes tools as state changes, the agent must not retain a stale tool after the user signs out, switches organizations, or leaves the workflow.
Our analysis of agent hooks that fail open explains the design rule: a missing policy layer should stop the consequential action, not quietly remove the check.
How to test one site tool
- Start with a reversible, low-value action such as saving a draft preference.
- Test valid, invalid, missing, oversized, and adversarial inputs.
- Change account, tenant, role, and session state before the call completes.
- Cancel the operation and verify that the server does not finish it later.
- Repeat the call to test idempotency and duplicate protection.
- Review the agent-visible description beside the actual server-side effect.
- Log the tool, user confirmation, validated inputs, result, and rollback path.
ChatGPT support has practical limits
OpenAI’s site-tools help page says support depends on the account, selected model, and page. It currently describes use in ChatGPT’s in-app browser, not through Chrome for this ChatGPT feature.
The OpenAI WebMCP Challenge closes September 3 at 1 p.m. Pacific and offers ten prizes of $3,000. Developers testing in Chrome need an experimental flag or origin trial. Those conditions are signs of an early platform, not reasons to build a critical production dependency without fallback.
My verdict: expose fewer tools with clearer consequences
WebMCP can make browser agents less brittle by replacing guessed clicks with actions the site intentionally exposes. That should improve reliability and accessibility for agent-assisted workflows.
The safe adoption path is deliberately small. Start with one reversible action, make its effect visible, keep authorization below the page, and require explicit confirmation when the action reaches money, messages, publishing, or account state. A structured tool is easier for an agent to use and easier for a developer to overexpose.
Read the current specification
- Review the WebMCP specification repository.
- Read OpenAI’s ChatGPT Site Tools documentation.
- Check the challenge rules and deadline.
Checked August 29, 2026. WebMCP is experimental. Browser, account, model, page, flag, and origin-trial availability can change as the proposal develops.
