v1.0.0 — Rush 1.0 (rebrand of che-transport-mcp)

Rush 1.0 — Taiwan TDX transport routing MCP. Rebrand of che-transport-mcp (same 27 tools, same routing behavior). Self-contained product repo: MCP source + plugin + marketplace.

Migration: existing che-transport-mcp users uninstall the old plugin and install rush. TDX credentials carry over (keychain service che-transport-tdx preserved). Repo renamed PsychQuant/che-transport-mcp → PsychQuant/rush (GitHub redirects old URLs).

Notarized universal binary Rush (arm64 + x86_64) attached for wrapper auto-download.

v0.11.0 — bus_rail_route (Stage 3c-i)

v0.11.0 — Stage 3c-i: bus_rail_route (bus→rail multi-modal)

The mirror of rail_bus_route: a journey that starts on a bus and ends on rail. Tool count 26 → 27.

Why the direction flip matters

In rail→bus the bus is leg 2, boarding at a future time, so the live A2 ETA is useless. In bus→rail the bus is leg 1, boarding now — so A2 live applies (source: live), making it the most accurate leg in the engine.

How it works (no RAPTOR)

Forward dual of 3b-ii's reverse search: among the bus routes serving from_stop, name-match the downstream stops to rail stations → candidate alight-hubs. Ride the bus (A2 live) to a hub, then the transit_route rail engine to to, anchored at the bus arrival + walk. transfer optional (explicit or auto-selected, bounded cap + disclosure). Earliest final rail arrival wins; auto_selected_transfer names the chosen hub.

Honest by design

• The timing chain: A2 gives a board, not arrival. When the bus is timetabled, the rail leg anchors at bus arrival; when frequency-only (arrival unknown), it falls back to board-time + walk with an approx_note — never presented as precise.
• No qualifying hub / rail unreachable / no direct bus → routes:[] + note; ambiguous endpoint → matches.

Verified

200 offline tests green. Live: full forward-search pipeline exercised end-to-end (resolution, name-match, honest empty+note). Explicit rail_bus_route and the three other tools frozen.

Deferred to 3c-ii (demand-gated, not built speculatively): multi-transfer and a unified RAPTOR core — the TDX data ceiling, not the algorithm, is the accuracy bound.

v0.10.0 — rail_bus_route auto-hub (Stage 3b-ii)

v0.10.0 — Stage 3b-ii: auto transfer-hub selection for rail_bus_route

rail_bus_route's transfer is now optional. Omit it and the hub is auto-selected; provide it and the frozen 3b-i explicit-transfer path runs unchanged. Tool count stays 26.

How auto-hub works (bounded, no RAPTOR)

to_stop-anchored reverse search: among the bus routes serving to_stop, walk upstream and name-match those stops (捷運X站/X車站) to rail stations. Only those are candidate transfer hubs — a handful, not all of Taiwan. For each candidate the rail leg (from → hub) + bus leg is stitched (reusing 3b-i), and the earliest-arrival itinerary is returned with auto_selected_transfer naming the chosen hub.

Honest by design

• Candidate set bounded by a cap (default 8, closest-upstream first); overflow disclosed in auto_hub_note — never silently truncated.
• Name-match is structured (臺↔台 normalized, district names like 南港 don't over-match), not geo.
• No qualifying hub / rail unreachable / no direct bus → routes:[] + note; ambiguous endpoint → matches.

Verified

188 offline tests green. Live end-to-end: 中壢 →(auto: 港墘)→ bus → 捷運市政府站, 4 legs, auto_selected_transfer set. Explicit path byte-for-byte unchanged. bus→rail and multi-transfer remain future work (3c).

v0.9.0 — rail_bus_route (Stage 3b-i)

v0.9.0 — Stage 3b-i: rail_bus_route (rail→bus multi-modal)

New tool rail_bus_route(from, transfer, to_stop, city, depart_after?) — rail leg to an explicit transfer station, then a name-matched bus leg to the destination stop. Tool count 25 → 26.

How it works (honest by design)

• Rail leg reuses the transit_route TRA↔Taipei-Metro engine (source: live/scheduled/frequency).
• Interchange found by name-match at the transfer station — 捷運X站 / X車站 / X火車站, normalized 臺↔台, with structured patterns (not bare substring) so district names like 南港 accept 南港車站 but reject 南港高工.
• Bus leg boards at rail arrival + walk with A2 live disabled — a now-snapshot can't time a future post-transfer boarding, so the board comes from the timetable (scheduled) or headway/2 (frequency); arrival is timetabled or honestly omitted + note.
• Output: legs (rail + one bus) + transfers (transfer + walk_min, estimated) + arrival_time + duration_min + transfer_count(=1). Ambiguous endpoint → matches; rail unreachable / no qualifying stop / no direct bus → routes:[] + note.

Scope

rail→bus single transfer, explicit transfer station, TRA+TRTC rail leg. Auto-hub-selection, bus→rail, and multi-transfer are future work (3b-ii).

178 tests green (offline); live-verified end-to-end against TDX. transit_route / bus_route unchanged.

v0.8.0 — bus_route: direct-route bus routing

v0.8.0 — bus_route: direct-route bus routing (Stage 3a)

New MCP tool bus_route(from_stop, to_stop, city, depart_after?) — direct-route within-city bus routing (no transfers). Stage 3a of the (B) routing engine north-star (臺灣版 NAVITIME).

Added

• bus_route — finds direct routes serving both stops (origin before dest, same direction; reuses the bus_find_routes StopOfRoute intersection), each with a board estimate — A2 live ETA (source: live) → next timetabled departure (source: scheduled) → headway/2 expected-wait (source: frequency) — and an arrival time from the Bus/Schedule per-stop timetable delta (source: scheduled) where the route is timetabled, omitted with a note for frequency-only routes (never faked). Ambiguous stop name → matches; no direct route → routes:[] + note (transfers deferred to 3b). Tool count 24 → 25.
• New Bus/Schedule endpoint + BusSchedule models (mixed Timetables / Frequencys).

Honest data ceiling

Probing real TDX shaped the design: bus has A2 real-time per-stop ETA (a now-snapshot) + mixed timetable/frequency schedule, but no static per-segment ride-time source. So board-ETA is live-first; arrival is timetable-backed or honestly omitted; transfers (A2 can't predict a future-time second boarding) are deferred to 3b.

Verification

• 169 offline tests, 0 failures (BusRouterTests ×5, BusRouteToolTests ×4 executor, BusSchedule decode, 25-tool JSON-RPC smoke).
• Live: bus_route(歡仔園 → 大觀路一段28巷, Taipei) → route 234, board in 3 min (source: frequency), arrival omitted (frequency-only route — honest, not faked).

Roadmap

Stage 1 (v0.6.0) TRA time-dependent · Stage 2 (v0.7.0) TRA↔Metro multi-modal · Stage 3a (this release) direct-route bus · Stage 3b bus↔rail multi-modal + transfers · Stage 3c unified RAPTOR core (deferred).

Install

Download che-transport-mcp-0.8.0.mcpb for one-click install in Claude Desktop. Developer ID signed + Apple notarized.

v0.7.0 — transit_route: TRA↔Taipei-Metro multi-modal routing

v0.7.0 — transit_route: TRA↔Taipei-Metro multi-modal routing (Stage 2)

New MCP tool transit_route(from, to, depart_after?) — the first tool that routes a journey across modes (台鐵 ↔ 台北捷運). Stage 2 of the (B) routing engine north-star (臺灣版 NAVITIME).

Added

• transit_route — time-anchored multi-leg composition over a curated interchange registry. TRA legs reuse the timetable + live TrainLiveBoard delay (source: live/scheduled); metro legs use expected-wait headway/2 at the metro-entry band (source: frequency — TDX metro has frequency, not per-vehicle departure phase). Cross-system transfers only at curated interchanges (台北車站 / 板橋 / 南港 / 松山, IDs probed from live TDX). Endpoints resolve across both systems; same-name metro platforms collapse into one logical station; a vague/multi-station name → matches; no route or TRA-timetable outage → routes:[] + note (empty ≠ error). Tool count 23 → 24.
• Reuses both existing routers unchanged — rail_route (Stage 1) and metro_find_route are untouched.

Verification

• 158 offline tests, 0 failures (MultimodalRouter / InterchangeRegistry / TransitTools executor + 23→24 JSON-RPC smoke).
• Live: transit_route(中壢 → 西門) → TRA 自強 1136 中壢 08:03 → 臺北 08:57, transfer @ 台北車站 (walk 5), 板南線 台北車站 → 西門, arrive 09:09 (66 min, 1 transfer).

Roadmap

Stage 1 (v0.6.0) = TRA time-dependent. Stage 2 (this release) = TRA↔TRTC multi-modal. Stage 3 (future) = unified multi-modal core + bus + fuller live feeds. Accuracy is bounded by TDX data shape, not the algorithm (see CLAUDE.md North Star).

Install

Download che-transport-mcp-0.7.0.mcpb for one-click install in Claude Desktop. Developer ID signed + Apple notarized.

v0.6.1 — Security patch (minutesOfDay overflow guard)

v0.6.1 — Security patch

Fixed

• Integer-overflow DoS in minutesOfDay (TimetableRouter + MetroTools): caller-supplied depart_after (and malformed timetable/headway data) flowed into h * 60 with no bounds, and Swift traps on overflow — a multi-digit hour crashed the server. Now bounds the HH/mm components before the multiply (which also validates the time). Flagged by automated security review of v0.6.0. (No behavior change for valid input.)

Developer ID signed + Apple notarized.

v0.6.0 — rail_route: TRA time-dependent routing

v0.6.0 — rail_route: TRA time-dependent routing (Stage 1 of the routing engine)

New MCP tool rail_route(from, to, depart_after?, system) — TRA time-dependent O/D routing (#7). It routes over the real DailyTrainTimetable (per-train departure/arrival times) with a connection-scan earliest-arrival search, then applies live TrainLiveBoard delays so the chosen itinerary reflects current conditions: a delayed train can lose to a later on-time one. This is Stage 1 of a staged time-dependent, live-aware transit routing engine (MCP-native, Taiwan-deep).

Added

• rail_route returns legs[] (train_no, from/to station, dep/arr times, delay_min, source: live | scheduled) + arrival_time + duration_min. TRA-only (the only mode with both a public timetable and a live delay board); distinct from rail_find_trains (which lists all trains). Tool count 22 → 23.
• Reuses existing RailODFare/RailStopTime/RailLiveTrain models + existing registry endpoints (both arrive v3-wrapped; decoded via TDXDecode.list). Graceful when the timetable (HTTP 500/empty) or live board is unavailable — empty + note, never a crash; missing live data → all legs scheduled.

Verification

• 143 offline tests green, incl. TimetableRouterTests (the live-delay-changes-the-chosen-train case) + executor graceful-degradation tests.
• Live: rail_route(臺北 1000 → 臺中 3300, now) → train 111, 臺北 08:00 → 臺中 09:49, 109 min, source: live.

Roadmap (#7)

Stage 1 (this release) = TRA. Stage 2 = headway modes (metro/bus) as synthesized connections. Stage 3 = unified multi-modal CSA/RAPTOR + full live feed.

Install

Download che-transport-mcp-0.6.0.mcpb for one-click install in Claude Desktop. Developer ID signed + Apple notarized.

v0.5.0 — Metro cross-line transfer routing

v0.5.0 — Metro cross-line transfer routing

metro_find_route now does cross-line transfer routing, not just direct (#6). The metro network is modelled as a graph (stations as nodes; same-line adjacency from S2STravelTime; transfer edges from the new LineTransfer dataset, weighted by walk time + estimated boarding wait) and the shortest path is returned. A direct route is simply a zero-transfer path — so the same query also catches cases where a 環狀線 transfer beats a long direct ride.

Added

• Cross-line transfer routing in metro_find_route. New metroLineTransfer registry endpoint + MetroLineTransfer model + contract case (contract cases 30 → 31). Single-line systems (HTTP 400 / empty) degrade gracefully to no transfer edges. Tool count unchanged (22 — extends the existing tool).

Changed

• metro_find_route output shape evolved from v0.4.0's flat single-line shape to routes[], each with legs[] (one leg per line ridden — line name/colour, per-leg travel time, headway), transfers[] (one per line change — interchange station, from/to line, walk_min, estimated wait_min), transfer_count, and total travel_time_min. The #5 direct short-circuit gate is replaced by always building the graph.

Verification

• 135 offline tests green (incl. MetroGraphTests: shortest path, circular-shortcut-beats-direct, single-line graceful, unreachable).
• Live: metro_find_route(臺北車站 → 淡水, TRTC) → 1 transfer at 台北車站 (BL→R, walk 4 + wait 4) + 淡水信義線 ride → 45 min. metro_find_route(臺北車站 → 南港, TRTC) → 0-transfer 板南線, 19 min.
• metro endpoints (incl. LineTransfer) live-contract green.

Install

Download che-transport-mcp-0.5.0.mcpb for one-click install in Claude Desktop. Developer ID signed + Apple notarized.

v0.4.0 — Metro O/D direct routing

v0.4.0 — Metro O/D direct routing

New MCP tool metro_find_route(from, to, system) — direct (single-line) metro O/D routing across the 6 metro systems (TRTC / TYMC / KRTC / TMRT / NTDLRT / KLRT). Returns the connecting line (name + colour), station-to-station travel time, and current-period service headway. Metros run on headways, not fixed timetables, so it does not return a specific departure time. No direct line → empty routes + transfer hint. Direct-only; transfer routing tracked in #6. (#5)

Added

• metro_find_route tool + MetroModels (StationOfRoute / S2STravelTime / Frequency / Line). Tool count: 21 → 22.
• 4 metro routing endpoints added to the TDXEndpoints registry + live contract enumeration (contract cases 26 → 30). No inline metro path literals — all resolved through the registry.

Notes

• Travel-time accumulation is direction-agnostic: TDX S2STravelTime stores segments one-way only (e.g. 板南線 stores descending order), and adjacent-station run-time is symmetric. Headway is selected by Asia/Taipei weekday + time-of-day band.

Verification

• 130 offline tests green; metro 4/4 live-contract green.
• Live: metro_find_route(臺北車站 BL12 → 南港 BL22, TRTC) → 板南線, 18 min, 8–10 min headway.

Install

Download che-transport-mcp-0.4.0.mcpb for one-click install in Claude Desktop. Developer ID signed + Apple notarized.