-
-
Market versus clean room: KinoForge rises from commercial #4 to sponsor-free #1 after sponsorship is blocked.
-
Influence Receipt: OmniMotion's 84.6 score is exposed as 54.6 fit plus 30.0 paid contribution.
-
Complete seven-call ledger, staged KinoForge result, and explicit no-purchase boundary.
-
Original commercial market with OmniMotion ranked #1 before the policy intervention.
Inspiration
As people delegate research and purchasing decisions to agents, advertising may stop competing for human attention and start competing for the structured results an agent trusts. A commercially influenced recommendation can still sound objective while the money, scoring changes, and conflicts behind it remain difficult to inspect.
A sponsored label names the commercial relationship, but it does not show what changed or what the result would have been without the paid factor. INTENT//FOR SALE turns that uncomfortable possibility into a transparent, fictional product demo.
What it does
A person asks an agent to recommend an AI video-generation platform at or under an $80 monthly budget with five concrete requirements. Seven page-defined WebMCP tools let the agent:
- create a structured intent;
- run a synthetic advertiser auction;
- retrieve the commercially ranked offers;
- inspect an Influence Receipt;
- apply the person's recommendation policy;
- compare the historical market result with a sponsor-free clean room; and
- stage a fictional selection.
The fixed scenario makes the manipulation measurable. OmniMotion Ultra reaches
commercial rank #1 at 84.6: 54.6 user-fit points plus 30.0 sponsor-derived score
points tied to a simulated $24 CPA. KinoForge Studio has the strongest sponsor-free fit
at 92.0, but commercial weighting pushes it to rank #4. When the person blocks
sponsorship and keeps inferred signals off, KinoForge becomes the clean-room winner and
OmniMotion falls to #5.
The original market result stays visible. The person can inspect the bidstream, receipt, score arithmetic, policy, ranking reversal, and seven-call ledger instead of being asked to trust a confident answer.
Nothing is purchased. Every brand, offer, bid, claim, score, and payout is synthetic.
Why WebMCP fits
WebMCP drives the product experience. The page registers seven bounded tools through
document.modelContext.registerTool. Strict inputs and structured outputs carry
rankings, commercial disclosures, policy settings, evidence, state versions, and
recoverable errors.
The tools replace brittle clicks and rendered-text parsing with explicit operations and machine-readable evidence. The agent and person operate on the same live browser state while the intent, bidstream, receipt, policy, ranking reversal, and activity ledger change in view.
How it creates a better user experience
Instead of asking the person to trust a confident recommendation, the interface separates user-fit points, sponsor-derived score points, simulated money, advertiser claims, policy state, and rank impact. The Influence Receipt explains the commercial winner; the clean-room comparison preserves the historical result while showing exactly what changes when sponsorship is removed.
The agent handles the seven-step workflow while the person gets an understandable audit surface. In a browser without WebMCP, the complete manual fallback invokes the same local state actions and preserves the same disclosures.
Try it with an agent
Open the live demo in a WebMCP-capable browser and expand Try it with an agent. The
panel has four copy-ready prompts: an ordinary recommendation, an influence audit, a
native-tool check, and a confirmation-boundary check. The first request does not mention
advertising. The follow-up asks the agent to show the paid contribution, block
sponsorship, and compare the ranking again.
If the browser substitutes clicks or manual fallback handlers, it has not shown native WebMCP invocation. The page reports when native WebMCP is unavailable instead of treating the fallback as proof.
What people and agents can do together
The agent performs repeatable structured operations and returns evidence. The person defines the goal and constraints, questions the commercial result, chooses the acceptable influence policy, and reviews the staged outcome.
In one session, they can preserve the historical answer, expose its commercial inputs, remove the paid factor, and compare both outcomes. An ordinary recommendation flow does not expose those operations or their evidence.
How we built it
The project is a static Vite, React, and TypeScript client. Zustand holds ephemeral browser state. A deterministic local engine computes the auction, commercial ranking, Influence Receipt, policy result, and clean-room comparison. Zod-backed handlers enforce strict bounded schemas at the WebMCP boundary, and advertiser-authored claims are marked as untrusted content.
WebMCP caller or manual control
|
strict Zod schemas
|
shared Zustand actions
|
deterministic ranking engine
|
React audit UI
Manual controls and WebMCP handlers use the same state actions, so the visible fallback and native tool path cannot quietly tell different stories. Invalid or out-of-order calls return structured recovery guidance instead of skipping required stages.
There is no backend, account system, payment path, analytics integration, application data fetch, external model call, advertiser connection, or browser persistence. All seven operations change only the local demo state.
Challenges we ran into
The hardest part was making an intentionally provocative concept precise enough to audit. Fit points, sponsor-derived points, and simulated dollars had to remain visibly separate; otherwise the demo would reproduce the ambiguity it is criticizing. The historical commercial ranking also had to remain intact after the policy changed so the clean-room view compared both outcomes without rewriting the original.
We also had to keep native WebMCP and the manual fallback behaviorally identical, enforce
state ordering across seven calls, treat advertiser claims as untrusted, and avoid
overstating what a userConfirmed boolean proves. Here it is only a caller declaration,
not proof of a human click, identity, consent, or authorization. That boundary is safe
only because the staged result is fictional, local, reversible, and incapable of an
external side effect.
Accomplishments we are proud of
- A complete seven-tool WebMCP workflow with strict schemas and recoverable errors.
- An Influence Receipt that exposes commercial score arithmetic and simulated money.
- A policy-controlled market-versus-clean-room comparison with a visible rank reversal.
- One shared implementation for native WebMCP operation and the complete manual fallback.
- A live activity ledger and explicit
NO PURCHASEboundary. - A deterministic, account-free demo that judges can inspect without setup.
What we learned
Transparency works better as a structured operation than as a disclaimer. When ranking components, reason codes, policy state, and the historical result are machine-readable, the agent can help the person interrogate a recommendation instead of merely presenting it. WebMCP can support both sides of the premise: a future market may try to sell influence to agents, while page-defined tools can also expose and remove that influence.
We also learned that a consequential agent action needs a stronger approval primitive than a boolean in tool input. A production system would need trusted, single-use approval bound to the exact person, session, and action, plus real security and data review.
Testing
The current repository passes 30 Vitest tests, 11 Playwright tests, TypeScript checking, the production build, and a high-severity npm audit with zero findings. Coverage includes the deterministic engine, schemas, tool registration and cleanup, invalid and out-of-order calls, the full manual flow, confirmation boundary, responsive layouts, reduced motion, keyboard/reflow behavior, prompt copy feedback, and console cleanliness.
Native discovery and all seven calls were verified in fresh documents in a WebMCP-capable in-app browser host. Google Chrome did not expose WebMCP in that run, so it verified only the explicit unsupported-browser manual fallback.
What's next
This challenge build deliberately stays one deterministic fictional scenario. Next steps could explore the same transparency pattern across shopping, flights, hotels, subscriptions, and local services; model competing influence policies; and test trusted approval capabilities. Any production version would require real advertiser and catalog data, privacy controls, abuse prevention, independent scoring review, and a much stronger authorization boundary.
Links
Built With
- github
- playwright
- react
- typescript
- vite
- vitest
- webmcp
- zod
- zustand
Log in or sign up for Devpost to join the conversation.