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:

  1. create a structured intent;
  2. run a synthetic advertiser auction;
  3. retrieve the commercially ranked offers;
  4. inspect an Influence Receipt;
  5. apply the person's recommendation policy;
  6. compare the historical market result with a sponsor-free clean room; and
  7. 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 PURCHASE boundary.
  • 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

Share this project:

Updates

Submission history