Inspiration
Repair troubleshooting is split across two worlds. The browser can search current model records, official recalls, guides, and troubleshooting material, but it cannot see whether a filter blocks light, hear a scrape, feel a binding wheel, or inspect a hidden label. The person can make those observations, but should not have to manually reconcile every source, hypothesis, diagnostic check, and stop condition.
Repair Relay turns that split into a useful collaboration instead of pretending an agent can inspect a physical object remotely.
What it does
Repair Relay is a persistent, evidence-first repair workbench for low-risk consumer-device triage. The agent identifies the product, checks official safety information, gathers current repair sources, maintains competing hypotheses, and proposes safe diagnostic checks. The person reviews those checks, performs them in the physical world, confirms or corrects the exact observation, and retains final authority over the repair plan.
Each confirmed observation creates visible supports, contradicts, or eliminates relationships. The cause ranking and plan change for reasons the person can inspect. Recall matches and affirmative battery, smoke, electrical, gas, refrigerant, or pressure hazards stop normal diagnostics and create a professional-help state.
Why this is a strong fit for WebMCP
The value depends on shared page state. A separate chatbot would duplicate the case and obscure which facts came from public sources, the agent, or the person. Screenshot-and-click automation would be brittle and would not provide reliable schemas, lifecycle control, provenance, idempotency, or a visible trust transition.
WebMCP lets the agent operate the same durable case the person sees. Tools update the visible source board, diagnostic proposals, evidence graph, pending human attestations, plan, and history. Tool availability changes with case state, so the browser agent discovers only actions that are valid now.
How it creates a better user experience
Repair Relay does not return a wall of generic advice. It asks for the safest physical observation most likely to change the answer.
Agent-relayed physical evidence is not silently accepted. It appears as a pending statement in the page. The person confirms it, corrects it, or rejects it. Only then can the evidence graph and plan change.
Safety is enforced before diagnostics. Consequential changes remain pending. Approval waits for the trusted human control. The complete case survives refresh, every mutation has provenance, and Undo restores the previous snapshot.
What people and agents can do together
In the showcase case, the agent finds the live Dyson V8 record, checks CPSC, gathers current repair material, and proposes low-risk checks that distinguish filter restriction from airway blockage, battery weakness, and motor fault.
The person reports that bright light is almost completely blocked by the dry removable pre-filter. The browser cannot obtain that physical result. Repair Relay holds the relayed statement until the person confirms it. The confirmed observation raises filter restriction, weakens competing causes, and stages a revised plan with assumptions and stop conditions.
The agent can open the approval checkpoint but cannot approve. The call resolves only after the person acts in the page. Refresh preserves the case; Undo restores the previous snapshot.
How WebMCP was implemented
The TypeScript client uses imperative document.modelContext.registerTool registration with a compatibility path for the earlier preview surface. Eight focused tools share the same CaseService as the human interface:
- search_products
- open_repair_case
- get_case_context
- search_repair_sources
- add_observation
- propose_diagnostic_steps
- record_test_result
- approve_repair_plan
Tools use closed JSON Schemas, runtime revalidation, compact structured output, typed failures, trust annotations, stable identifiers, idempotency keys, and AbortController lifecycle cleanup. Registration is state-driven. Mutating tools disappear while human evidence is pending, and plan approval exists only during the human-review state.
The Cloudflare Worker and D1 database store guest sessions, canonical cases, source cache, idempotency responses, and append-only before/after events for real rollback. CPSC is treated as the official safety source. iFixit is clearly labelled as community repair guidance.
Challenges
The hardest boundary was distinguishing “the agent relayed what the person said” from “the person confirmed that physical observation.” Treating those as the same event made the agent appear successful while bypassing the product’s central trust claim. The final flow makes that transition explicit and blocks downstream mutation until it is resolved.
The second challenge was keeping a rich evidence model understandable. The interface now prioritizes the active decision, describes evidence as relative support rather than calibrated confidence, and collapses secondary provenance and history details until needed.
Release boundary
The source repository is canonical Repair Relay. A public deployment URL and public narrated YouTube demo must be attached only after the exact release commit passes public-origin WebMCP, live-source, persistence, and refresh verification. The previous Label Relay deployment and video are not evidence for this product.
Built With
- cloudflare-d1
- cloudflare-workers
- cpsc
- ifixit
- playwright
- typescript
- vite
- vitest
- webmcp