wheelchair and maxWalkingTime sit alongside modes on tripgo-routing, so an unsuitable trip is never generated rather than being discarded once it is. The surface ends at planning and lookup — routing, nearby locations, departures and a trip link, with no booking or ticketing tool among them. Everything is positional: you need coordinates before you can ask anything, and a geocoder is not part of the tool set.
A public-transport routing server over TripGo: coordinates and stop codes go in, trips, nearby locations and departures come back.
- Point-to-point routing from a fromLat/fromLng pair to a toLat/toLng pair, anchored on either a departureTime or an arrivalTime.
- Trip shaping on the same call: modes to consider, a maxWalkingTime ceiling, a wheelchair flag, and a limit on how many trips come back.
- Nearby stops and stations around a lat/lng within a radius, filtered by modes.
- Departures for named stopCodes in a region at a given timeStamp.
- A link for a planned trip, from the tripURL it was returned with.
Nothing to supply — no account, no key. Latitude and longitude for both ends of the journey, since the server takes coordinates rather than place names; departures additionally need the stopCodes and the region they belong to.
One command — npx mcp-remote https://tripgo-mcp-server.skedgo-account.workers.dev/mcp