Jumping Beans

The future of web interaction is two-sided, driving user intent upstream and letting merchants set the path. We let users see the offers they want, how they want, when they want it-powered by WebMCP.

Comment

One request. Three sites. One human approval boundary.

Tell Jumping Beans: “Coffee under $15. Show customer stories first.” It turns that intent into an editable selection. Only after you approve it does the browser discover offer tools from three independently hosted demonstration storefronts, ask each site for structured matches, and assemble one explainable result. Every card says where it came from and why it appeared. Nothing has to be saved.

That is the core idea: agents can do the repetitive cross-site work, while people keep control of context, retention, and consequential actions.

Inspiration

Shopping on the open web is fragmented. People repeat the same category, budget, and presentation preferences on every site. Agents can help, but a general-purpose agent is often forced to infer meaning from changing page layouts, and shoppers cannot easily see which site supplied a fact or what personal context crossed a boundary.

We wanted to explore a different model: the browser as a user-controlled capability network. Each participating site publishes a narrow, structured tool; the shopper decides when a request may leave the current page; and the result carries its source, decision reasons, and retention policy with it.

Why WebMCP

Jumping Beans is not a chat box wrapped around a catalog. Its central action crosses real browser origins. The Engine loads three independently hosted demo storefronts, discovers each site's get_matching_deals tool with document.modelContext.getTools, and invokes the returned capabilities with document.modelContext.executeTool.

That makes WebMCP essential:

  • sites opt in by registering their own tools and remain authoritative for their own product records;
  • the browser exposes structured capabilities instead of making an agent guess through page markup;
  • one approved preference can be projected narrowly to several sites without sharing an identity or an entire profile;
  • every origin succeeds, returns no match, times out, or fails independently; and
  • the same journey is visible to the person and available to the agent as a structured receipt.

The result is a concrete model for an open agentic web: coordination without turning every website into one centralized API.

What people and agents can do together

A person can start in plain language or choose a tested recipe. Jumping Beans converts the request into an editable category, an exclusive budget, and presentation rules such as testimonials first, price proof, comparison, or no urgency.

An agent can inspect or stage display preferences, build the offer journey, read browser-scoped offer memory, inspect the active profile, and retrieve a redacted journey receipt. The person still decides whether to use the selection for one visit or save it in the browser, and whether network sharing is active. Draft choices stay on the page until they are applied.

After approval, the Engine calls the three storefront tools, validates their responses, applies the shopper's rules, ranks eligible offers, and shows the result with source provenance. The shopper can then open a storefront carrying only the reviewed visit-level presentation context.

On the Watch Co demo storefront, a declarative register_interest form shows a second collaboration pattern. A visitor or agent may fill a product and target price, but that only stages the action. The page requires separate human confirmation before Watch Co records a non-binding, 30-day demand signal. It does not create an order, reservation, notification, payment, or message.

How we built it

The project uses plain HTML, CSS, and JavaScript modules across four deployed origins: one Cloudflare Worker for the Engine and three Cloudflare Pages demonstration storefronts. Cloudflare D1 backs the optional Engine account experience and the separate Watch Co demand-signal store.

Each storefront registers one bounded get_matching_deals tool. The Engine creates cross-origin iframes with explicit tool and isolation delegation before navigation, waits for registration, discovers only the three allowlisted origins, and executes each tool with WebMCP's JSON-string input contract.

The Engine also registers six page-level tools: get_offer_memory, set_display_preferences, build_offer_journey, set_deal_watch, get_profile, and get_journey_receipt. Watch Co additionally exposes a declarative register_interest form.

The trust boundary is part of the implementation. Production responses use COOP, COEP, CORP, an exact three-origin Permissions Policy, and an origin-trial token on every origin. Partner responses are origin-checked, schema-validated, limited to 24 records and 64 KiB, and bounded by independent deadlines. Invalid or expired offers never become partner cards. Preference projections omit identity and carry only the approved category, price ceiling, and display rules. The Watch write path revalidates server-side, binds the staged payload, requires page confirmation, and uses idempotency to suppress duplicate commits.

Non-WebMCP browsers still get a useful, honestly labeled storefront-preview journey. That lane demonstrates the same category, budget, and presentation handoff but never claims a native WebMCP match.

Challenges

The hardest problem was making a multi-origin native journey reliable and honest. Partner registration is asynchronous, and an early shopper action exposed a cold-start race that a later diagnostic probe could accidentally hide. We changed the test order so the user action happens before any direct registry inspection, waited at the iframe registration boundary, reconciled tool-change events, and tested repeated fresh browser profiles.

Browser builds also differed on whether tool input arrived as serialized JSON or an object. We made the production path follow the JSON-string contract and kept a narrowly scoped compatibility retry only for recognized input-type errors.

The other challenge was semantic: distinguishing an open-catalog sample, a response from a demo WebMCP origin, a presentation-only storefront preview, and a consequential write. We added explicit labels, per-origin outcomes, provenance, retention copy, staging, confirmation, and receipts so the interface never makes a stronger claim than the underlying event supports.

What we learned

The best human-agent experience is a handoff, not full automation. Agents are excellent at discovering capabilities, making parallel structured requests, and summarizing evidence. People should own the moment when context leaves a page, whether it persists, and whether a consequential action proceeds.

We also learned that provenance is product UX. A source label, a no-match state, and a decision receipt make a cross-site result easier to trust than an opaque “best deal” answer. For an emerging browser capability, isolation headers, feature enrollment, fresh-profile timing, and failure behavior matter as much as the tool code itself.

Competition work

This is a new project. The repository's first commit was created on August 27, 2026, after the competition opened on August 25. All source code, product design, deployment configuration, documentation, and acceptance work in v0.11.0 was created during the submission period.

The exact live v0.11.0 release passed a release-bound 38/38 native WebMCP audit in a fresh, headed, extension-free Chrome Stable 152.0.7977.76 profile, plus 10/10 fresh-profile cold starts. The release workflow passed 812 product assertions and a nine-case responsive-browser matrix.

Release: https://github.com/stevekkall-beansgc/jumping-beans/releases/tag/v0.11.0

What's next

The next experiment is a browser-native aggregation origin that can fan out to vertical or geographic storefront groups while preserving each underlying origin and result. We would also replace demonstration storefronts with authorized real partners, expand beyond retail matching, and reuse the same consent and receipt model for support and other multi-site journeys.

Built With

Share this project:

Updates

Submission history