MIRROR//LOOP

Eleven native WebMCP tools turn a 12-step reflection into a safe human-agent workflow: the agent clarifies and navigates, the browser scores, and the person confirms every choice.

Comment

Inspiration

People are surrounded by instant answers, motivational shortcuts, and confident-sounding advice. Under stress, more output often creates more noise. MIRROR//LOOP creates a deliberate pause: twelve everyday questions help a person notice the pattern they reach for first, then turn that pattern into one small, practical next step. The challenge was not simply to put a quiz on a webpage. A 12-step reflection connected to 144 cards can be difficult to understand quickly, especially when a visitor is uncertain, tired, or using unfamiliar language. WebMCP makes the existing experience easier to navigate without making the agent the authority over the person.

What it does

MIRROR//LOOP is a live, privacy-bounded reflection experience. The normal website works on its own, while a compatible browser agent can use eleven typed WebMCP tools to:

  • start or resume the reflection;
  • read the active question;
  • explain one choice in plain language;
  • neutrally compare two choices;
  • record or revise only an answer the person explicitly confirms;
  • review all confirmed answers;
  • preview how one hypothetical change would affect a completed result without saving it;
  • complete the deterministic 12-answer reflection;
  • export a local Markdown or JSON dossier after confirmation;
  • retrieve any public card from 001 through 144; and
  • recommend a relevant digital edition without changing a cart or starting payment.

The page remains fully usable when WebMCP is unavailable. When registration succeeds, it visibly reports WebMCP ready · 11 tools. A collapsible Agent State rail shows tool registration and invocation activity on the page, so a judge can see the human-agent workflow without keeping DevTools open.

Why WebMCP

Traditional browser automation must infer intent from visual controls and presentation markup. A conversational model may also invent meanings when the site's authoritative definitions are not available as structured capabilities. WebMCP lets MIRROR//LOOP expose the actions that already belong to the page as typed, same-origin tools. The agent handles explanation and navigation; the browser retains the confirmed answers and applies the scoring rules; the person controls meaning, consent, identity, email, cart changes, and payment. This is the central design principle: the agent reduces friction without taking authority. A participant can say, “I am torn between these two choices.” The agent can call compare_choices and return the site's own neutral contrast. It cannot silently choose. When the participant decides, answer_reflection_question requires confirmed_by_user: true before browser-local state changes. The boundary is enforced by the tool implementation, not merely by conversational wording.

How we built it

The public experience is built with semantic HTML, CSS, and modular JavaScript. web/lib/webmcp.js registers eleven tools through the browser model-context surface. Each tool uses a closed JSON Schema with additionalProperties: false, bounded runtime validation, behavioral annotations, and structured errors. The 12-question scorer runs deterministically in browser memory with stable ascending-code tie-breaking. The public card registry exposes curated metadata for Cards 001–144 without publishing private prompt engineering or source corpora. The Agent State rail listens for decoupled lifecycle events—registration, tool start, and tool completion—and displays a privacy-filtered input summary, observed local elapsed time, outcome, and human-confirmation state. Observability cannot interrupt the underlying reflection action. The production website uses Firebase Hosting with a small Go submission service on Google Cloud Run. Cloudflare Turnstile protects only the optional reflection-email request. It loads when the visitor reaches the email form, and the Go API verifies the short-lived token with Cloudflare before storing a pending subscription or sending email; the secret remains in Google Secret Manager. Turnstile does not control the reflection, WebMCP, the cart, Stripe Checkout, or payment.

Safety and privacy boundaries

MIRROR//LOOP does not give the agent a general-purpose browser or purchasing capability.

  • Recording or revising an answer requires explicit human confirmation.
  • A hypothetical preview never changes saved answers.
  • Local dossier export requires a separate confirmation.
  • No WebMCP tool submits an email address.
  • No WebMCP tool changes a cart, creates a Checkout Session, or makes a payment.
  • Individual choices stay in the browser for the normal reflection and local-export paths.
  • Optional email delivery is a separate, disclosed request handled by the submission service.

The tool installer reports readiness only after every registration resolves. If registration fails or WebMCP is unsupported, the complete direct-use experience remains available with an honest fallback status.

Challenges we ran into

The hardest problem was defining a useful agent boundary. A tool suite can become impressive-looking but unsafe if it turns interpretation, communication, and commerce into one broad authority. We repeatedly narrowed tool inputs and outputs, separated read-only tools from state-changing tools, and made confirmation a runtime requirement. We also had to make a complex symbolic system understandable without exposing private research material or forcing visitors to learn internal terminology. The answer was selective context: return one current question, one exact card, or one bounded comparison rather than loading the entire system into every agent turn. Finally, experimental browser support required feature detection, graceful fallback behavior, strict character budgets, and a reproducible Chrome test path.

Accomplishments that we are proud of

  • Eleven purpose-built WebMCP tools operating one coherent, visible user journey.
  • Explicit human confirmation enforced before answer mutation.
  • Deterministic browser-side scoring rather than model-authored results.
  • Exact public retrieval across a 144-card matrix.
  • A visible Agent State rail that makes tool execution legible without DevTools.
  • Read-only commerce recommendations with identity and payment kept outside agent authority.
  • A one-command WebMCP evaluation runner covering registration, schema limits, confirmation rejection, premature completion, output budgets, and the no-checkout boundary.
  • A production deployment with a complete non-WebMCP fallback.

What we learned

WebMCP is most valuable when it does not merely automate clicks. It gives a website a second, agent-readable interface while preserving the visible human interface as the shared source of truth. Good tools are small, typed, and auditable. They return authoritative local context, expose clear state transitions, and refuse actions that should remain human. We also learned that an agent experience must be demonstrated visibly. Registration badges, progress changes, focus movement, live regions, and the Agent State rail make the collaboration understandable to people as well as machines.

What's next

Next we will publish the final public demo video, complete the Devpost media package, and continue testing with WebMCP-capable agents. Product work will focus on clearer first-time orientation, broader accessibility checks, and measured user research. Future capabilities will keep the same boundary: reflection and retrieval may be agent-assisted, while identity, communication, cart, and payment remain explicitly human-controlled.

Challenge-period work

The landing page, quiz, card data, email flow, cloud deployment, and human-controlled Stripe Checkout existed before the challenge. The eleven WebMCP tools, strict schemas, explicit answer-confirmation boundary, revision and preview flows, 144-card lookup, safe edition recommendation, visible readiness and Agent State UI, browser verification, evaluation corpus, and submission evidence were added during the challenge period. The public repository history documents those additions.

Built With

Share this project:

Updates