OutcomeMesh

Ask once, approve once: dinner and a ride booked via WebMCP

Comment

Inspiration

Jordan uses a wheelchair. Booking dinner and a ride tonight means two websites, and the restaurant's site gives an AI assistant nothing to call. Agents can navigate many websites, but navigation is not a safe, inspectable action contract. Cross-site tasks still break when a capability is missing, a route violates a human constraint, consent is vague, or one provider fails after another action already succeeded.

OutcomeMesh explores a different layer: a neutral control plane between web capabilities and human outcomes. The open web needs both a way to create missing agent-native supply and a way to route that supply under visible human control.

What it does

Deterministic, fixture-driven demo: two bundled sample connector packages stand in for community submissions; all providers are synthetic.

The demo begins with one synthetic intent: dinner tonight at 7 for two people, wheelchair accessible, with a ride included and a total budget under $80. The page registers six WebMCP tools when it loads; the header shows the live count (6 WebMCP tools live for your AI assistant). Restaurant booking is not one of them, so the outcome cannot complete.

Community Foundry reviews a sample restaurant connector package, submitted the way a community package would be. The risky version is rejected; the safe version passes an executable 18-check validator and is published with document.modelContext.registerTool(...). The header count changes from 6 to 8 without a reload, and the Step 2 screen lists every WebMCP call as it runs: publish_connector twice, plan_outcome, then the brand-new restaurant_search_accessible_slots.

Router rejects a cheaper restaurant because its entrance has three steps, and shows the exact plan: $44 restaurant + $26 ride = $70, who receives what data, and the cancellation boundary. Nothing is booked until the person presses Confirm on the page. An agent that calls execute_outcome earlier receives a structured consent_required result, and the page shows that call as Needs your OK.

After Confirm, Step 4 lists the booking calls: execute_outcome, restaurant_hold_slot, and then stepway_book_accessible_ride, which runs on a second origin (https://outcomemesh-provider.pages.dev). The first ride fails deterministically, the table stays held, and only the ride is retried. Done shows one confirmation, RCPT-OM-0007, with exact prices and cancellation windows.

Why this use case is a strong fit for WebMCP

WebMCP is the lifecycle being demonstrated, not an add-on. The restaurant tools genuinely do not exist at startup. Community Foundry publishes them with the imperative API; a WebMCP-aware browser then discovers and calls them as structured, page-origin tools. Chrome DevTools' Application → WebMCP pane shows the same eight tools plus the provider tool, with live invocation status. If WebMCP is unavailable, the demo blocks instead of pretending that a badge or browser macro created native tool supply.

The provider ride is a real cross-origin WebMCP call: the synthetic Stepway page registers stepway_book_accessible_ride with exposedTo limited to the OutcomeMesh origin, and OutcomeMesh discovers it with getTools({ fromOrigins }) and runs it with executeTool only after the page-owned consent grant.

How it creates a better user experience

The human and agent share one visible state. The agent receives structured tool schemas instead of guessing at page controls. The human sees why one route was rejected, exactly what data will be shared, who receives it, what will change, what costs $70, and which boundary is irreversible before anything consequential executes. Every tool call is visible on the page as it happens, with its origin, so trust does not depend on a hidden log.

Accessibility needs change which tools are called: the route with three entrance steps is rejected even though it is cheaper. This is a fixture-driven demonstration, not validated accessibility evidence.

What people and agents can do together that was difficult before

An agent can inspect the page's current capabilities, publish the missing sample connector package, create the route, and attempt execution. The page stops it at a human-only approval boundary, then exposes the approved state so the agent can resume and retrieve the same receipt the person sees. Together they complete a multi-provider task while preserving provenance, constraints, consent, failure, recovery, and outcome evidence across the full loop.

How we built it

React, TypeScript, and Vite, using WebMCP's imperative API. Six platform tools register when the page initializes:

  • inspect_capabilities
  • publish_connector
  • plan_outcome
  • approve_outcome
  • execute_outcome
  • get_outcome_receipt

Foundry publication dynamically registers two domain tools:

  • restaurant_search_accessible_slots
  • restaurant_hold_slot

A second static origin hosts the synthetic Stepway provider page, which registers stepway_book_accessible_ride for the OutcomeMesh origin only.

Every registered tool is wrapped so each call (from the page or from a browser agent's executeTool) is recorded with its origin and result and rendered on the Find and Book screens. Tool callbacks, Router, the consent checkpoint, execution, recovery, event ledger, and receipt all read and mutate one deterministic runtime store. A Playwright verifier uses native getTools() and executeTool() to prove the 6 → 8 lifecycle, the cross-origin provider call, receipt integrity, and recovery. Hosting is two static Cloudflare Pages projects; there is no backend, login, or API key.

Challenges we ran into

Keeping one system instead of two: a visual workflow plus a nominal WebMCP layer would have been easy and dishonest. Every visible phase and every tool callback share one state machine.

Modeling failure honestly: a pre-consent stop resets to a safe six-tool state because nothing mutated; after a consequential mutation the UI starts a fresh proof and does not claim provider rollback.

Browser differences: Chrome's WebMCP testing surface parses executeTool input as a JSON string, so the runtime tries the object form first and falls back to a string.

Accomplishments we are proud of

  • The page-origin registry really changes from six to eight tools without a reload, and the page shows the count live.
  • A second website's WebMCP tool is discovered and executed cross-origin, only after visible human consent, and the call is shown with its origin.
  • Exact rejection, least-privilege consent, deterministic failure recovery, and one combined receipt stay synchronized.
  • Zero-key, deterministic, responsive, keyboard-operable, runnable without accounts or services.

What we learned

The strongest WebMCP experience is not "an agent can click less." It is that a website can expose a precise capability contract while the human stays inside the same visible state and consent boundary. Dynamic availability matters as much as schema quality, and a receipt is credible only when it is derived from the same actions the tool callbacks actually performed.

What's next

Validate one agent builder who wants the Action Contract／connector workflow and one website owner who wants to provide it. The prototype does not claim that demand, adoption, payment, or production integration evidence exists.

Built With

Share this project:

Updates