An app knows what its buttons do. Making an agent rediscover that from the screen is a peculiar arrangement.
WebMCP proposes a more direct route: a web page exposes structured actions that a compatible browser agent can call. The page can remain a place where a person sees the work and intervenes. This is a Draft Community Group Report, not a finished W3C standard or a promise of support in every browser.
Our earlier account, The Agent Is the Session, explored this through uk.gov Radar. The enduring idea is shared work: an agent can help operate the page without making the person abandon it.
The page can explain what it does before an agent starts guessing.
Explanation and sources
Inside the Radar Explore page, a founder clicks Keep while a browser agent calls a tool the page declares through WebMCP: search_items, read_item, propose_founder_profile, suggest_item, set_aside_items, read_workspace or draft_brief. Without declared tools, an agent wanders across the screen guessing which button does what. The button and the tool reach the same shared workspace functions and change the same shortlist. Outside the page, an assistant reaches a service through an MCP server: no open page, a different scope with its own checks.
- WebMCP draft
- Radar implementation
The same shortlist, two ways to work
Radar's Explore workspace collects government information relevant to AI founders. A founder can filter items, keep a shortlist and prepare a brief. The agent needs those same operations.
The implementation registers actions for searching, reading an item, proposing a profile and working with the shortlist. The controls and tools call shared workspace functions. A proposed profile stays visible for the founder to review. Suggestions can be kept or dropped.
This matters when judgement changes. A grant can match the search criteria yet be wrong for the business. Keeping the evidence and decision on the page lets the person correct the agent at the point where the mistake becomes clear.
Shared functions help keep these routes consistent. They do not make mistakes impossible. State changes, invalid inputs and unavailable services still need handling. Our recorded example shows one implementation; it is not a general reliability benchmark.
Similar names, different jobs
A graphical interface exposes controls. People choose them; events trigger the app's behaviour. An API exposes operations to another program. A command-line interface makes operations available through commands, often useful for repeatable work.
MCP, the Model Context Protocol, connects AI applications to servers that expose tools and context. WebMCP concerns actions exposed by a web page to browser agents. An app may have reasons to use several of these routes.
The choice depends on where the work belongs. A person reviewing a shortlist benefits from seeing changes beside their sources. A background job may need a server connection without an open page. Neither arrangement is automatically more accessible or more appropriate.
Chrome's current guide documents a WebMCP origin trial from Chrome 149 and a flag for local development. It covers actions defined through JavaScript and annotated forms. That is a route to testing an integration. Support still needs checking in the browser and agent people will actually use; the trial does not establish support everywhere.
Context still has to cross a boundary
An agent may already know something relevant about a person. That can reduce repeated entry. It does not mean the app has no need for accounts, or that everything the agent knows stays private.
When the agent passes a profile field to a page tool, that field has crossed into the page. Authentication and access checks remain necessary where the operation requires them. The useful design question is which information this action actually needs, and whether the person can inspect what is being proposed.
Our original article took a strong position on where context could live. This adaptation narrows the claim: keeping some context with the agent can change what a site needs to store. The result depends on the application and the information sent to its tools.
Start with an action worth exposing
Choose a task where navigation gets in the way of judgement. Define the action clearly, show its result and make correction possible. Compare it with the existing controls, including failure cases. Fewer guessed clicks are promising; a correctly completed task is the evidence.
The next article examines hands-free control through Traction. It brings speech into the picture and asks how the person knows that an instruction actually worked.