Orchestra AIBy Hyperdrift

WebMCP and shared state / UI and accessibility

Stop making agents hunt for buttons

WebMCP lets a page expose actions to a browser agent. Radar shows how that can keep the person and agent working in the same place.

By Yann VR · 4 min readShare article ↓Discuss an app your users should be able to direct →
Evidence reviewed 5 October 2026 · Method and maintenance

An app knows what its buttons do. Making an agent rediscover that from the screen is a peculiar arrangement.

WebMCPDraft Community Group Report · 30 September 2026WebMCPDefines structured actions exposed by web pages for compatible agents. Browser support needs separate verification. It does not establish that an app is accessible.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab) 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 SessionYann VR · Hyperdrift · August 2026The Agent Is the SessionThe original Radar account. The Orchestra adaptation narrows its claims about accounts and context: information passed to a page tool crosses into the page.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab), 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.

Stop making agents hunt for buttonsInside 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.PART 3 OF 6 · UI & ACCESSIBILITYStop making agents hunt for buttons.The page says what it can do. You and the agent change the same work.radar.hyperdrift.io/exploreTHE PAGE THE FOUNDER SEESgrantsdeadlinesourceInnovate UK smart grantKeepAI skills fundDropR&D tax relief guidanceKeepTHE PAGE DECLARES · WEBMCPsearch_itemsread_itempropose_founder_profilesuggest_itemset_aside_itemsread_workspacedraft_briefAgentcalls byname?Youclick Keepguessing from the screencalling a declared toolShared workspace functionsa button and a tool change the same shortlistOUTSIDE THE PAGE · MCPAssistant → MCP server → serviceNo open page. A different scope, with its own checks.RADAR WEBMCP IMPLEMENTATION · TOOL NAMES AS REGISTEREDai.hyperdrift.io/articles/webmcp-actions-on-the-page
Stop making agents hunt for buttonsInside 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.PART 3 OF 6 · UI & ACCESSIBILITYStop making agentshunt for buttons.The page says what it can do. You andthe agent change the same work.radar.hyperdrift.io/exploreTHE PAGE THE FOUNDER SEESgrantsdeadlinesourceInnovate UK smart grantKeepAI skills fundDropR&D tax relief guidanceKeepYouclick Keepguessing from the screencalling a declared toolTHE PAGE DECLARES · WEBMCPsearch_itemsread_itempropose_founder_profilesuggest_itemset_aside_itemsread_workspacedraft_briefAgentcalls a toolby nameShared workspace functionsa button and a tool change the same shortlistOUTSIDE THE PAGE · MCPAssistant → MCP server → serviceNo open page. A different scope,with its own checks.RADAR WEBMCP IMPLEMENTATION · TOOL NAMES AS REGISTEREDai.hyperdrift.io/articles/webmcp-actions-on-the-page
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.

Sources reviewed 5 October 2026. Conceptual diagrams are labelled separately from the reported scan.

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 implementationHyperdrift · implementation notesWebMCP in UK AI RadarDescribes tools that operate the same workspace as the page controls. This is our own implementation account, not independent validation.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab) 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 ProtocolModel Context Protocol · version 2026-07-28MCP architectureExplains hosts, clients, servers and tool discovery and invocation. Our spoken, cross-app release-note example is a proposed application of these mechanisms.Orchestra editorial summary · reviewed 1 October 2026Open original ↗ (new tab), 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 guideChrome for Developers · guide updated 1 October 2026WebMCPDocuments an origin trial from Chrome 149 and a local development flag. A route to testing, not support in every browser and agent.Orchestra editorial summary · reviewed 5 October 2026Open original ↗ (new tab) 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 CommanderOrchestra · related articleA spoken promise is not a completed actionA Cargo recovery request becomes an action, a checked result and a spoken report. What this bounded demonstration can teach app designers.Orchestra editorial summaryOpen original ↗ (new tab). It brings speech into the picture and asks how the person knows that an instruction actually worked.

Discuss an app your users should be able to direct.

Know someone working on this? Pass it on.

Put the idea to work

What would this look
like for you?

Tell us about one workflow and the tools involved. We’ll discuss where agents could help and which decisions should stay with your team.

A personal reply within one working day.

We’ll use these details to reply to your enquiry.