WebMCP Operator Workspace

Inspiration## Inspiration

A website should be able to tell an AI agent what it can do, rather than making the agent infer every operation from visual controls.

We built WebMCP Operator Workspace to explore a practical question: how can a human and an agent share an operational workspace while keeping capabilities contextual and sensitive decisions human-controlled?

What it does

The application presents a fictional hotel refrigeration incident across two pages: Case Workspace and Asset Inspector.

In Case Workspace, an agent can read the incident, prepare a work plan, draft a customer update, select equipment components and prepare contextual observations. Prepared work appears in the interface for the human to review.

The capability surface changes with context:

• Case Workspace initially exposes 11 tools.
• Selecting a component activates two additional tools, bringing the total to 13.
• Clearing the selection withdraws those tools, returning to 11.
• Navigating to Asset Inspector exposes six tools for that page.

For sensitive proposals, the application separates preparation from approval. Applying a pending proposal is blocked. A human reviews it and clicks Approve in the page. The agent can then apply that proposal once; repeating it is rejected.

There is no registered WebMCP tool to approve a proposal. On Asset Inspector, the agent can prepare an inspection note, but the final form save remains a human UI action.

How we built it

The project is a standalone application built with HTML, CSS and JavaScript, hosted on GitHub Pages.

It registers structured capabilities through document.modelContext.registerTool(). Contextual tools are withdrawn using AbortSignal, and each document registers its relevant tool surface.

A semantic capability tree describes declared pages, interface regions and capabilities. It distinguishes application contracts from runtime observations: observing an unexpected tool does not automatically add it to the application's authorized surface.

Navigation uses declared page identifiers rather than arbitrary URLs. Proposal handling uses explicit states and single-use approval consumption.

The reviewed candidate passed 49 automated tests covering application contracts and behaviors, including approval states, replay rejection and contextual lifecycle scenarios. GitHub Actions runs the test suite.

Challenges we faced

The main challenge was separating three concepts: discovering a capability, preparing work and having authority to apply a sensitive proposal.

Contextual tools must disappear when their context ends. Registration failures must not leave a partially active surface. Navigation must expose the destination page's capabilities rather than preserve stale assumptions.

We also needed the interface to distinguish a prepared draft from a saved note, and an approved proposal from an applied action.

What we learned

WebMCP is useful not only for exposing operations, but also for making the agent-facing interface reflect the current application context.

Visible shared state helps the human understand what the agent prepared. Explicit approval states make the transition from proposal to application understandable and testable.

Accomplishments

We combined contextual tool registration, a multipage capability surface, visible agent-prepared work and a human approval workflow in one publicly accessible application.

The result demonstrates a complete application-level sequence: proposal, blocked premature application, human approval, single application and replay rejection.

How to try it

Open the live application with a WebMCP-compatible agent client and enter the workspace.

Ask the agent to read the case, select condenser_fan, prepare an observation and clear the selection. Next, request a sensitive-action proposal and observe the blocked attempt before approving it manually. Ask the agent to apply the approved proposal and then repeat the same proposal to test replay rejection.

Finally, navigate to asset-inspector and prepare an inspection note without submitting the human form.

The application does not require our developer tunnel, proprietary Universal MCP runtime or credentials. An ordinary browser can display the human interface, but agent invocation requires a WebMCP-compatible client.

Scope and limitations

All incident, customer and equipment data is fictional. State is in memory and local to the active page; reloads and navigation do not promise persistence.

Drafts do not send messages. Applying a proposal records a local demo event; it does not dispatch a technician or operate real equipment.

The approval boundary demonstrates application workflow enforcement, not server-side authentication or protection against arbitrary browser automation.

The accompanying video is an AI-generated explanation created with NotebookLM, not a screen recording of execution.

What's next

We would explore further usability testing and carefully scoped operational integrations. Persistence, identity and server-enforced authorization would require additional design before production use.

Built With

• actions
• css3
• github
• html5
• javascript
• node.js
• webmcp