ONCE — Tell Your Story Once

The 15-second version

One story in. Four services staged. Two schedule conflicts avoided. One unjustified Government ID request blocked. Zero applications sent before approval.

ONCE is a working WebMCP demonstration of a better contract between a person, their chosen agent, and essential-service websites. The agent does the coordination; the person keeps the authority.

Inspiration

People facing one urgent life event often repeat the same painful story across disconnected forms. Each form asks for a slightly different set of personal data, appointments collide, and the person cannot see what an automated helper disclosed. We wanted to show a different web: tell one chosen agent once, let participating services expose precise capabilities, and keep one visible plan and final human authority.

This is a documented service-design problem, not only a demo premise. The OECD reports that complex information and cumbersome application procedures contribute to non-take-up of social support. GOV.UK service guidance recommends avoiding repeated questions, collecting only necessary personal information, and explaining the purpose of every field.

What it does

The working demonstration lets a person tell an agent one urgent story: their home is unsafe, three children need temporary shelter, food and a health check, and the family needs accessible transport within 72 hours. The agent projects that story into reversible, non-sensitive local planning constraints, then coordinates four fictional provider simulations. It checks the simulations' published eligibility rules deterministically, avoids calendar conflicts, identifies the minimum purpose-bound fields for each service, blocks an unjustified Government ID request, and stages one coordinated plan.

An outcome rail makes the result immediately inspectable: one story, four staged services, two avoided conflicts, one blocked overreach, and zero applications sent before approval. prepare_assistance_plan returns the same structured evidence to the agent.

The agent can prepare and explain. It cannot approve. The person reviews every exact value beside its provider-declared purpose, then approves or rejects the proposal. An unjustified field is shown as withheld without revealing its value. Only after approval does WebMCP expose the consequential commit tool. Approval is fingerprint-bound, expires in five minutes, and can be used once. Synthetic receipts and an audit trail make the result visible.

How we used WebMCP

We use the Imperative API to register small, state-aware tools for updating planning constraints, reading intent, service discovery, deterministic eligibility, disclosure inspection, audit reading, plan preparation, visible review, and approved commit. Tools use the current standard read-only and untrusted-content annotations. Registrations are cancelled and rebuilt when page state changes, so the update capability disappears after staging and commit_approved_plan is literally absent until the person approves in the page.

This is more than controlling buttons. WebMCP supplies a typed collaboration contract between the simulated service network, the agent, and the human. The agent receives concise structured results instead of scraping an interface, while every tool execution updates the human-visible state. The visible buttons remain as a progressive fallback and invoke the same application actions.

The chosen agent receives approved planning constraints but never receives the synthetic Government ID or health notes. Provider simulations receive only purpose-approved fields after the person approves the exact proposal.

What makes the experience new

Today, agents often automate one website at a time and maximize data collection for convenience. This demonstration treats one life event as the unit of coordination, not one website: a local intent is selectively projected into four provider simulations, each field is purpose-bound, untrusted provider text is handled as data rather than authority, and capability increases only when the human explicitly opens the gate. It demonstrates the browser-side contract that independent services could use to form a user-controlled cooperative network; it does not claim that real agencies are connected today.

Existing care-navigation systems validate the need for multi-service discovery and enrollment. Our distinct category is not “another benefits chatbot”: the civic journey is a test case for a transferable consent boundary between a person, their chosen agent, and WebMCP-enabled sites. Most agents are optimized to finish a task; this demonstration shows how to finish without surrendering the person's data boundary or final authority.

How we built it

React, TypeScript, and Vite power the visible bilingual English/Arabic experience. A deterministic domain engine handles eligibility, disclosure minimization, scheduling, fingerprints, expiring approval, and single-use receipts. The WebMCP adapter registers phase-specific tools with JSON Schemas and security annotations. Vitest and Testing Library cover the engine, UI journey, tool calls, dynamic registration, cancellation, and error handling; Playwright verifies the full browser flow and responsive layout.

Challenges

The hardest boundary was separating agent initiative from human authority. Hiding a button is not sufficient: the tool itself must be undiscoverable before approval, then bound to the exact reviewed proposal. A second challenge was treating service content as untrusted without making the agent blind. The demo uses browser trust annotations plus a deliberately bounded heuristic for a synthetic adversarial notice; this is evidence of the boundary, not a claim to solve prompt injection generally.

Accomplishments

A coherent multi-service journey instead of a single form wrapper A visible and machine-readable coordination outcome rather than an unexplained success screen One-story projection into reversible planning constraints without accepting Government ID or health notes Minimum necessary disclosure with a visible overcollection block Quarantine of malicious provider instructions without discarding the provider's legitimate service Dynamic WebMCP capabilities tied to human-visible state Deterministic eligibility and scheduling rather than model-made decisions Expiring, single-use exact-proposal approval Bilingual, responsive UI with visible audit and synthetic receipts Automated quality gate with 44 unit/integration tests, 17 browser journeys, and 91.98% statement coverage Accessibility, keyboard, responsive desktop/tablet/mobile, RTL, and WebMCP lifecycle browser checks passing Chrome agent audits passing for registered WebMCP tools, schema validity, the agent accessibility tree, and llms.txt

Evidence behind the problem

OECD, Modernising Access to Social Protection (2024): https://www.oecd.org/en/publications/modernising-access-to-social-protection_af31746d-en.html GOV.UK, Collecting personal information from users: https://www.gov.uk/service-manual/design/collecting-personal-information-from-users GOV.UK, Structuring forms: https://www.gov.uk/service-manual/design/form-structure GOV.UK, Principles for securing personal data in government services: https://www.gov.uk/guidance/principles-for-securing-personal-data-in-government-services

What we learned

WebMCP works best when tools describe durable user goals, not DOM operations. Security annotations help agents reason about risk, but they do not replace careful product boundaries. The clearest trust mechanism is shared state: the person should see the same plan, disclosure, approval, and result that the agent sees.

What's next

A production version would use authenticated provider schemas, cryptographic consent receipts, wallet-mediated selective-disclosure credentials through the emerging Digital Credentials API, revocation, durable encrypted storage, provider accountability, and independent security/privacy review. This submission intentionally stays synthetic so its current guarantees are clear and testable; it does not claim signed credentials or zero-knowledge proofs.

Built with

WebMCP Imperative API, React, TypeScript, Vite, Vitest, Testing Library, Playwright.

Verified in ChatGPT Work

Beyond scripted browser tests, we completed a fresh, uninterrupted run against the public deployment in the official ChatGPT desktop built-in browser using ChatGPT Work and GPT-5.6 Sol Light. ChatGPT discovered ONCE's native Site tools, staged proposal fp_d264dc20, confirmed commit_approved_plan was absent before visible approval, observed it appear afterward, called it exactly once, received four matching synthetic receipts, and verified that the capability disappeared after use. The demo opens with the real ChatGPT result beside the current production interface; the main production capture independently demonstrates the complete WebMCP lifecycle.

Built With

• chrome
• playwright
• react
• testing-library
• typescript
• vite
• vitest
• webmcp