Inspiration

A broken wheelchair should not leave its user managing a second problem: figuring out who is doing what about the repair.

Consider two updates: the supplier reports sending an estimate, while the insurer reports not receiving it. The user still needs to know what happened and whom to ask next.

MobilityRelay focuses on that gap: turning conflicting reports into a clear, source-backed next step while keeping the user in control.

What It Does

MobilityRelay is a voice-and-text wheelchair repair coordination workspace, built as an independent Alexa+ experience simulator with a real MCP server.

Wheelchair users and caregivers can:

  • Record dated updates attributed to their sources.
  • Identify unanswered questions and inspect the supporting evidence.
  • Prepare contextual requests for review.
  • Approve an exact recipient and message.
  • Save local follow-up items.
  • Export a source-linked HTML or JSON case history.

The central moment in our fictional demonstration is precise: received does not mean approved.

A reviewed reply confirms that the insurer received the estimate. The receipt question is answered, but authorization remains pending. The next request addresses the remaining question.

Changed evidence invalidates outdated approval. The user must prepare and review a fresh request. In the demonstrated configuration, approved messages are captured locally, not delivered as email.

How I Built It

The React and Vite interface connects to a TypeScript/Express host. The official MCP TypeScript SDK handles tool discovery and runtime calls over Streamable HTTP, with protocol tests covering version 2025-11-25.

Six MCP tools power the repair workflow:

  • record_repair_event
  • get_repair_brief
  • prepare_repair_request
  • send_approved_request
  • manage_repair_followup
  • export_repair_packet

SQLite preserves case history, while TypeScript and Zod support validated contracts. Optional Ollama interpretation maps supported conversational requests to validated views; facts are rendered from current MCP records.

English dictation and spoken responses complement the text interface. Dictation remains editable and never submits automatically.

Challenges I Ran Into

The hardest challenge was preserving meaning as evidence changed. Sent, received and approved are different events. The application must not turn a partial confirmation into an unsupported conclusion.

We addressed this through deterministic rules, source-linked answers and explicit review before saving changes.

Approval is bound to the exact recipient, message and case version. Updated evidence makes old approval unusable. Failed connections do not automatically replay writes.

We also refined speech lifecycles, loading recovery, responsive layouts and the visibility of review decisions.

Accomplishments I am Proud Of

  • Recorded QA includes 231 passing unit/integration tests and 142 passing desktop/mobile browser checks using fictional records.
  • The 2:57 demonstration exercises all six MCP tools and an actual Ollama inference through the working application.
  • The workflow visibly distinguishes confirmed receipt from pending authorization.
  • The exported history preserves sources and unresolved questions, with optional known-identity redaction for user review.

These are implementation results, not a claim of measured repair acceleration.

What I Learned

Trustworthy conversational software needs clear boundaries between what someone reported, what the evidence supports and what the user authorized.

MCP makes the workflow executable. Source attribution, persistent state and reviewed actions make it understandable and accountable.

When repair updates conflict, MobilityRelay helps the user ask the next clear question, backed by a record they can hand over.

Built With

Share this project:

Updates

Submission history