uestra-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| stop_searchA | Search stops/stations in the Hannover region (GVH/ÜSTRA) by name. Returns name, stop ID (e.g. de:03241:11), locality, type and coordinates. Use it to find the exact stop ID. |
| departuresB | Live departures at a stop in the Hannover region: planned time, real-time time (with delay in minutes), line, product, destination and platform. Accepts a stop name or a de: stop ID. |
| journey_plannerA | Plan public-transport journeys in the Hannover region (GVH/ÜSTRA/DB) from one stop to another, with real-time data. Names are resolved to the best matching stop automatically. Default: departing now; set departure or arrival (ISO 8601, local Berlin time if no zone) to plan for a time. |
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 3 tools
Each tool targets a distinct task: stop_search resolves stop IDs, departures returns live departure boards, and journey_planner handles routing between stops. There is no meaningful overlap—finding a stop, checking departures, and planning a trip are clearly separate actions.
All names are snake_case, but the patterns differ: stop_search (noun_verb), departures (bare plural noun), and journey_planner (noun_noun). The lack of a single verb_noun convention makes the set less predictable, though each name is still readable and descriptive.
Three tools map cleanly onto the core transit workflow (find stop, view departures, plan journey) with no redundancy. The surface is slightly thin—no coordinate-based or nearby-stop lookup—but each tool earns its place.
The set covers the essential lifecycle: resolving stops, real-time departures, and journey planning with time parameters. Minor gaps exist (no nearby-stop-by-coordinates search or service-disruption/line-info lookup), but agents can work around them using stop_search.