LiftCheck

• 

  Source and freshness are visible beside each station check. A report is evidence, never a physical-access guarantee.

• 

  Synthetic replay: the alternate elevator is checked independently. An unsafe workaround stays blocked.

• 

  Live MBTA check with report timestamps and sources. Riders can inspect the selected entrance and platform.

The problem

An elevator outage can break a particular entrance-to-platform path without closing a whole station. Advice to use another entrance is only useful when that alternative's elevators have also been checked. Existing accessible trip planners and outage subscriptions already help riders; LiftCheck focuses on the exact station dependencies of a saved routine and on explaining what changed.

What we built

LiftCheck checks selected station entrances and subway platforms at Assembly, State and Malden Center in Boston. A user chooses the actual entrance, platform and boarding/exit direction, then saves up to four station checks as a journey. Draft checks can be edited, removed and reordered. A saved journey can be reused as a new draft without changing the original. One complete MBTA snapshot is used for all the saved legs.

The application joins directed GTFS pathways to facility IDs and current alerts. It excludes stairs and escalators, preserves direction, applies alert time windows, and separately evaluates each alternative. A result distinguishes no reported closure, a different mapped entrance, a reported blockage and unknown evidence. It never turns a missing report into a claim that an elevator works.

The browser is a real MCP client. It negotiates MCP 2025-11-25 over Streamable HTTP and calls the same six registered tools that a compatible AI assistant can use. The server handles route computation and evidence; a connecting assistant can handle the conversation. No model decides station-path status, and no imitation chat parser or Alexa device connection is claimed.

The interface shows a readable sequence of the path’s elevator dependencies, with written status, source mode and retrieval time. On a phone, the sequence becomes vertical. A changed form selection is distinguished from its previous report. Expired live evidence withdraws the path view rather than leaving a reassuring diagram on screen. The design review documents the primary-source guidance, actual browser checks and remaining limits.

The demonstration

The revised demonstration opens with an explicitly labeled replay: Assembly elevator 717 closes, and LiftCheck proposes Revolution Drive after checking its elevator dependencies 718 and 719. Closing 719 too withdraws that alternative. An expired feed produces unknown with no path. The replay uses a real source map and invented outages; it is not presented as current transit information.

The demo then switches to an actual current MBTA fetch, shows source times and facilities, saves the chosen path as a journey, reloads it, and exposes the working MCP connection. Its final section states the three-station scope and the absence of rider or Alexa-device testing. The narration is synthetic speech generated with Google Gemini, not a rider testimonial or an Alexa recording. The video uses native 4K browser source frames with measured timing and held frames; 30fps describes delivery, not a claim of 30 independent source captures per second.

Why this use of MCP matters

A language model should not guess whether a workaround's second elevator is available. Typed tools preserve the user's exact station/platform context, evaluate the dependency graph, and return source URLs, active periods, topology hashes and retrieval time. The response supplies enough evidence to explain a failure and enough uncertainty to avoid pretending the task is resolved.

The working visual client makes these results inspectable without requiring an Alexa device during judging. The entry follows the self-hosted MCP path, not a claim of an account-linked Alexa add-on or a voice simulation.

What was tested

The prototype passes 48 engine/adapter/reviewer/transport checks and 5 browser stories after the interface redesign. A separate agent wrote 20 adversarial cases and found defects that were fixed and retested. Actual public-data fetches succeeded; the web application and an official SDK client exercised the actual server. Manual browser review also exercised draft editing, ordering, removal, cancellation, copying and persistence, plus 390px/320px layouts, visible keyboard focus and bounded contrast checks. Source provenance and a reproducible importer are included. These checks are not a full accessibility audit or rider validation.

Limits and next work

This is a three-station prototype. A public OpenAI Sites version now runs the same engine and real MCP tools at https://liftcheck.dgkv.chatgpt.site. Hosted journeys persist in a browser-scoped workspace; other browsers and external MCP clients have separate saved state. Outdoor paths, entrance hours, slopes, gate widths, train operation and boarding assistance are not verified. “No reported closure” is not an accessibility guarantee. Real riders and real Alexa devices have not tested it. Before expanding, the next work is supervised rider workflow research, remote Alexa account linking and comparison against the official MBTA/Transit workflow for the same saved station task.

All work was produced with AI assistance, including coding, independent agent review, interface design and Google Gemini synthetic video narration. No customer endorsements, physical station checks or performance advantage over competing apps are claimed.

Actual developer feedback

The current event rules were used to choose the self-hosted MCP path and protocol version. Reconciling the event's acceptable local demonstration with the general Alexa add-on documentation's remote/authenticated deployment path required several separate documentation reads. A single track checklist that distinguishes a conforming local MCP demo, a permitted agentic simulation and an actual account-linked Alexa add-on would make this clearer.

We built a real SDK transport test to verify negotiation of the specified protocol. A sponsor-provided conformance fixture for this exact entry path would help entrants show runtime integration consistently. No device onboarding or service authentication attempt was completed, so no device/API failure is asserted here.

Built With

• express.js
• gtfs
• javascript
• mbta-api
• model-context-protocol
• node.js
• playwright
• python
• zod