Navitia MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NAVITIA_REGION | No | Coverage region id the server is scoped to | fr-idf |
| NAVITIA_API_KEY | Yes | Your Navitia token | |
| NAVITIA_BASE_URL | No | API root (override for a self-hosted Navitia) | https://api.navitia.io/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_placesA | Geocode / autocomplete stations, addresses, POIs and cities by free-text query. Returns object ids usable as from/to in plan_journey or as stop_id in departure/schedule tools. |
| places_nearbyA | List public-transport stops and POIs within a radius of a coordinate. Useful to find the nearest station to a location. |
| search_pt_objectsA | Find public-transport objects (networks, lines, routes, stop_areas, transportation modes) by name and return their ids. Use this to resolve a line to its id — e.g. 'metro 14' -> a 'line:...' id — to pass as line_id in next_departures/stop_schedules, or to forbid a line, transportation mode or network in plan_journey. |
| plan_journeyA | Compute public-transport journeys between two points (multi-modal door-to-door routing). Returns up to 'max_nb_journeys' itineraries with legs, times, transfers and any disruptions. To express a taste for or against a line without ruling it out, pass 'prefer_lines' / 'avoid_lines'; use 'forbidden_uris' to exclude something outright. |
| next_departuresB | List the next departures from a stop (station or platform), with realtime delays when available. |
| next_arrivalsA | List the next arrivals at a stop (station or platform), with realtime delays when available. |
| stop_schedulesB | Timetable at a stop, grouped by line and route: for each line/direction serving the stop, the next departure times. |
| terminus_schedulesA | Departure board for one line at a stop, grouped by final destination (terminus) — what you would see on a station display. Both a stop and a line are required: resolve the line id with search_pt_objects first. |
| route_schedulesA | Full timetable grid for a line or route: every stop along the way with the times of upcoming vehicles. Heavier output — prefer stop_schedules when you only care about one stop. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools have clearly distinct purposes: search_places handles geocoding, search_pt_objects resolves PT identifiers, and plan_journey covers routing. The schedule/departure tools overlap somewhat, but their descriptions differentiate granularity well enough for an agent to choose correctly.
Naming is readable and grouped by domain (search_*, *_schedules, next_*), but it does not follow a single consistent verb_noun pattern. places_nearby and plan_journey deviate from the otherwise mostly noun-based tool names.
The 9 tools are well-scoped for a public-transport MCP server. Each tool covers a distinct part of the workflow—place search, PT-object resolution, journey planning, and multiple schedule/departure queries—without unnecessary redundancy.
The set covers the full read-only workflow: resolve places and PT objects to IDs, plan journeys, and query departures, arrivals, or timetables at stop, line, and route granularity. There are no obvious dead ends because the search tools explicitly feed the routing and schedule tools.