Skip to content

fix: prefer exact station matches in lookup#21

Merged
davidyen1124 merged 3 commits intomainfrom
fix/station-lookup-exact-first
Sep 12, 2025
Merged

fix: prefer exact station matches in lookup#21
davidyen1124 merged 3 commits intomainfrom
fix/station-lookup-exact-first

Conversation

@davidyen1124
Copy link
Owner

@davidyen1124 davidyen1124 commented Sep 12, 2025

fix: prefer exact station matches in lookup

Problem

  • Substring matching could map “San Francisco” to “South San Francisco”.

Change

  • Update find_station matching order:
    1. exact equality on normalized names
    2. prefix match on normalized names
    3. substring match on full names (fallback)

Verification

  • Unit tests: 19 passed locally.
  • Manual: Connected with MCP Inspector (stdio); tools listed, list_stations returned data, next_trains for “San Jose Diridon” → “San Francisco” returned upcoming departures.

Notes

  • No API changes; internal matching only.
  • Abbreviation behavior (SF, SJ, diridon, etc.) unchanged.

Prioritize exact normalized name equality, then prefix matches, then substring.
Prevents 'San Francisco' resolving to 'South San Francisco' due to substring match.

Verified via MCP Inspector:
- tools/list OK
- list_stations OK (GTFS loads)
- next_trains OK for 'San Jose Diridon' -> 'San Francisco'

No API changes; pure internal matching logic tweak.
@davidyen1124 davidyen1124 merged commit 463f35c into main Sep 12, 2025
@davidyen1124 davidyen1124 deleted the fix/station-lookup-exact-first branch September 12, 2025 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant