RecallDesk

Turn a possible product recall into a source-backed follow-up plan. A persistent MCP case desk checks exact labels, requires confirmation, and resets old plans when recall instructions change.

Comment

Inspiration

Finding a recall notice leaves several practical questions: does the exact model match, which conditions still need checking, what does the source ask the owner to do, and what has already been done? A household should not have to reconstruct that context each time it returns to the issue. RecallDesk explores the gap between finding information and carrying a careful follow-up through later conversations. Its focus is a small, concrete handoff: keep the product identity, source evidence, decision and next step together.

What it does

RecallDesk is a local case desk for possible U.S. CPSC consumer-product recall matches. A user records the exact brand and model, retrieves candidate notices, and compares the label against the source. A similar model number remains a possible mismatch. A follow-up plan is prepared from the notice's own identification, remedy and contact text, and requires explicit user confirmation of the full identification conditions. The case stores user-reported progress and can be reopened later. Refreshing the selected notice checks its content; a change invalidates the earlier confirmation and progress while retaining historical snapshots. Users can download a dated JSON case packet and an all-day calendar file for a date they choose. The app sends no manufacturer message, refund claim, purchase or calendar invitation. Empty search results do not establish safety. An explicitly fictional, offline mode demonstrates the complete workflow without making claims about real products.

How it was built

The web interface is an actual Model Context Protocol client built with the official TypeScript SDK. It initializes a Streamable HTTP session, discovers twelve tools, and invokes the same server operations that another compatible MCP client can use. The implementation explicitly negotiates protocol 2025-11-25. Node.js, TypeScript and Express provide the local runtime; Zod validates tool arguments, and node:sqlite persists cases, command receipts and versioned history. The CPSC adapter permits only documented query keys and bounds response size, record count and request time. Sparse source fields are normalized for review. A stable hash covers the complete upstream record, with normalized fields also bound into the stored evidence. The interface uses native DOM APIs, HTML, CSS and Vite. It is a guided, deterministic workflow: there is no paid runtime model, Alexa device connection or access to Amazon's gated developer simulator. OpenAI Codex assisted implementation, testing and writing.

Challenges

The Alexa+ developer SDK, toolkit, CLI and official web simulator are unavailable to hackathon entrants, so the implementation follows the official FAQ's own-web-client route. A real MCP workflow also requires protocol negotiation, session identity and local browser access controls; a similarly shaped HTTP endpoint would not be equivalent. The CPSC probe exposed sparse fields: the structured model and manufacturer fields were empty even though the exact model appeared in the description and the company appeared as importer. Independent review then found that punctuation variants such as HH-200.1 and HH-200+ could pass an overly permissive model boundary. That defect was fixed with negative variant tests. Review also exposed stale UI evidence after a newer case response; authoritative case adoption now clears or reloads derived review, draft-label and confirmation state.

What works today

The prototype carries a case through evidence review, explicit confirmation, persisted follow-through, source-change review and export using real MCP calls. All 33 domain and transport tests pass in the development workspace and clean release package, including official-SDK negotiation, multiple MCP sessions, a SQLite-backed restart, overlapping mutations, exact/near-model behavior, bounded source failures and safe calendar export. Independent review has no open material findings. In the internal browser, we also verified incomplete/near-model guards, explicit fictional confirmation, saved progress after reconnect, two-client stale-write recovery, real JSON/ICS downloads, and a live CPSC search returning seven candidates followed by preparation of a proposed plan. No real product ownership or applicability was confirmed. The fictional source-change exercise cannot be applied to live cases. No new cash spending or paid runtime service was required.

What we learned

A retrieved record is evidence to inspect, not proof of product applicability. Useful details can live outside the fields their names suggest, and an unchanged publication date does not guarantee unchanged instructions. Persistence also needs more than saving a case: the visible source review, label draft and confirmation control must refer to the same version after reconnects or errors. Finally, a source-backed workflow needs precise completion language. Marking a step complete records a user's report; it does not certify that a product is safe or that a manufacturer has accepted a request.

What’s next

The next step is a small usability study with consenting adults and scripted product-label tasks: can they distinguish a possible match from confirmation, find the source conditions, recover a case, and understand why a changed notice requires review? That study has not been performed. Further development would improve retrieval for sparse notices, preserve more structured identification evidence, and add clearer source-change comparisons. A model-backed conversational layer could use the same MCP tools if tested separately. Native Alexa+ integration would depend on access to Amazon's developer tooling. Broader jurisdictions, remote multi-user access and automatic monitoring would each require their own data, access and evaluation work.

Built With

Share this project:

Updates

Submission history