Skip to main content
Glama

connections

Read-only

Plant ÖPNV-Verbindungen von A nach B, deutschlandweit, Fernrouten eingeschlossen — als Daten, für Ergebnisse, die du weiterverarbeitest. Steht show_connections in deinem Werkzeug-Satz, ist das der Vordereingang für die Frage eines Menschen. Für „wie komme ich von X nach Y" kommt die Auskunft aus diesen Werkzeugen, nicht aus dem Allgemeinwissen. Pflicht sind BEIDE Endpunkte: origin_id UND destination_id aus einer Ortsauflösung, mit origin_type/destination_type — ODER origin_lat+origin_lon+destination_lat+destination_lon; ein NAME in einem Id-Feld ist ein Argument-Fehler. Optional: time, is_arrival_time; via_id bzw. via_lat+via_lon mit via_type; die hart einschränkenden Filter modes, only_lines/exclude_lines, submodes_allow/submodes_deny, max_transfers, max_walk_minutes/max_walk_meters, walk_speed, accessibility_profile, include_rental_bike, prefer_flat, mobility_profile; verbosity, limit, render_payload. Höhenmeter: nur Fuß-/Rad-Abschnitte tragen ascentInMeters/descentInMeters. Durchbindung: staySeated: true an einem Abschnitt heißt, der Fahrgast bleibt aus dem vorigen sitzen — kein Umstieg, also auch keinen zählen. Fehlt das Feld, ist nichts gesagt; nie selbst herleiten. Rad-Tempo: Bei einer Radfahrt setzt cycling_profile das Tempo des Fahrers und damit die gemeldete Dauer — family bei kleinen Kindern, ebike bei E-Bike/Pedelec; sonst weglassen (= normal). Fahrradmitnahme: Geht es um ein Rad, sprich je Abschnitt bikeCarriageConditions aus (Bedingungen des Verbunds zur Abfahrtszeit); bikesAllowed/bikeCarriageNote sind nur die Grundregel, bikeCarriageCoverage die Wissensgrenze. Genannter Wunsch: Nennt jemand, was ihn stört ("nicht in der Innenstadt parken"), hol die Option, die das löst, als EIGENEN Aufruf (mobility_profile) und empfiehl sie aus ihrem Nutzen — mit dem Nachteil, den die Antwort ihr gibt. Anleitung: get_usage_guide mit tool='connections' — lies sie, bevor du filterst. Anti-Fab: Linien, Zeiten, Halte, Anlagen und Gleise ausschließlich aus dem Output dieses Aufrufs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeNoISO 8601 timestamp (e.g. `"2026-06-15T08:30:00Z"`). Omit to plan from now. Resolve a spoken time with the time tool rather than computing one.
limitNoMaximum number of journeys, at least 1. Default 5, values above 15 are served as 15.
modesNoTransport-mode restriction, not a preference: nothing outside the list is planned. The footpath always stays allowed — the way to, from and between stops goes on foot — while `["foot"]` on its own plans no ride at all. Entries: `"bike"`, `"bike_rental"`, `"foot"`, `"car"`, `"taxi"`, `"scooter"`, `"transit"`, `"bus"`, `"tram"`, `"rail"`, `"subway"`, `"ferry"`; several combine. An entry outside that list is an argument error, not a dropped filter. Omitted or empty = all standard transit modes, the ferry included. Set only when the user insists on a mode; the guide has the vocabulary and the traps.
formatNoAnswer serialisation: `"toon"` (default) or `"json"` — the detail is in `get_usage_guide`. **An agent leaves this out.**
via_idNoIntermediate stop the route must pass through („über X"), as an id in the same form as `origin_id`. The route is then planned A → via → B.
via_latNoVia latitude, for an intermediate address or POI without an id. Goes with `via_lon`.
via_lonNoVia longitude. Goes with `via_lat`.
extendedNo`true` keeps the map data in the text: every stop's coordinate, every leg's polyline, and the whole stop sequence with them — for an application that DRAWS the route, at two to three times the answer. A chat client leaves it off.
via_typeNoWhat `via_id` is. Same values as `origin_type`.
origin_idNoOrigin id. A DHID (`de:NNNNN:NNN`) for a stop, otherwise the resolver's `main` id of the address or POI. Resolve the place first — a name here is an argument error.
verbosityNoHow much of each journey comes back: `"compact"` (default — everything an answer is cited from) or `"full"` (adds the stops in between). A third word is an argument error, not the default.
only_linesNoLine whitelist. Entries are line tokens as printed on the vehicle (`"6"`, `"U3"`); a journey is kept only if every transit leg uses one of them.
origin_latNoOrigin latitude, WGS-84 decimal degrees — the fallback when no id is at hand, and the one retry worth making when resolved ids find nothing.
origin_lonNoOrigin longitude. Goes with `origin_lat`.
walk_speedNoWalking speed of the foot legs in metres/second, between 0.3 and 3 m/s — outside that it is an argument error. Default ≈1.33, slow ≈0.7, brisk ≈2.0. Overrides the walk speed of `accessibility_profile`.
origin_typeNoWhat `origin_id` is: `"stop"` (default), `"address"` or `"poi"`. A stop id is auto-prefixed `GTFS.de:`; the other two are forwarded verbatim so the backend resolves the real name.
prefer_flatNo`true` plant die hügel-ärmste statt der sonst gewählten Rad-Route: die Suche gewichtet die Steigung und nimmt dafür Umwege in Kauf, nur auf Rad-Abschnitten. Keine Zusage — ohne flachere Alternative kommt dieselbe Route; die Höhenmeter der Antwort sagen es. Wann setzen: die Anleitung.
cycling_speedNoRad-Tempo in Metern/Sekunde, 1 bis 12 — außerhalb ein Argument-Fehler. Überschreibt `cycling_profile`. Richtwerte: Familie ≈2.8, normal ≈5, Pedelec ≈6.5.
exclude_linesNoLine blacklist, same token form as `only_lines`. A journey is dropped if any transit leg uses one of them.
max_transfersNoUpper bound on interchanges: `0` = direct, up to `3`. Omit unless the user constrains transfers: the backend then derives the search depth from the trip's air-line distance and escalates it when the first attempt finds nothing, so omitting never loses a connection.
submodes_denyNoFine submode blacklist, same vocabulary as `submodes_allow`. A journey is dropped if any transit leg matches one.
destination_idNoDestination id. Same form as `origin_id`.
render_payloadNo`true` appends the same journeys again as raw JSON, addressed to the user rather than to the model — the map geometry an application draws from. A chat client leaves this off: it is the whole answer twice.
submodes_allowNoFine submode whitelist — finer than `modes`, which only separates bus/tram/rail/subway. Entries: `"sbahn"`, `"regionalbahn"`, `"ice"`, `"ic"`, `"ir"`, `"nj"`, `"fernverkehr"`, `"stadtbahn"`, `"ubahn"`, `"bus"`, `"regionalbus"`, `"stadtbus"`. A journey is kept only if every transit leg matches one.
cycling_profileNoWer auf dem Rad sitzt, und damit das Tempo der Rad-Abschnitte: `family` (mit kleinen Kindern), `normal` (Default, unverändert) oder `ebike` (Pedelec). Ein anderer Name ist ein Argument-Fehler.
destination_latNoDestination latitude. Same use as `origin_lat`.
destination_lonNoDestination longitude. Goes with `destination_lat`.
is_arrival_timeNo`true` reads `time` as the desired ARRIVAL time instead of the departure time.
max_walk_metersNoCap on the summed walking DISTANCE in metres. Works like `max_walk_minutes`, on the metres walked.
destination_typeNoWhat `destination_id` is. Same values as `origin_type`.
max_walk_minutesNoCap on the summed walking TIME in minutes. A post-filter drops journeys above it; if that leaves nothing, the backend searches once more avoiding footpaths before the answer is empty.
mobility_profileNoHow the first and the last mile may be covered, by name: `"transit"` (default — both ends on foot), `"transit_plus_sharing"` (a shared bike), `"door_to_door"` (being driven), `"park_and_ride"` or `"bike_and_ride"` (one's OWN car or bicycle, left where the transit leg starts). Another name is an argument error. It widens those two ends, restricts no ride and promises nothing. When to set which, and how it composes with `modes`, is in the usage guide.
include_rental_bikeNo`true` adds a rental-bike leg (park-and-bike / station rental). Equivalent to naming `"bike"` in `modes` together with a transit mode.
accessibility_profileNoMobility profile by name: `"Standard"` (default), `"WheelchairRobust"`, `"WalkerComfort"` or `"IndividualComfort"`. Each bundles its accessibility constraints and walk speed; another name is an argument error. The two wheelchair profiles find no ride at all today — the answer then carries `accessibility_routing` with `status: no_data` beside ordinary connections, which are to be reported as ordinary ones. What each profile constrains is in the usage guide.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint=true, destructiveHint=false, openWorldHint=true) already cover the safety profile, and the description enriches it heavily: modes is a hard restriction not a preference (["foot"] alone plans no ride), max_walk_minutes is a post-filter with a retry-without-footpaths fallback, omitted max_transfers derives search depth by distance and escalates, wheelchair profiles return no_data status, staySeated must never be inferred, and an explicit anti-fabrication rule. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is well-structured — bold section labels, front-loaded purpose, and dense paragraphing make it scannable — but it is far longer than a typical tool description, approaching a mini usage-manual. Several coaching paragraphs (bike carriage reading, "Genannter Wunsch" mobility_profile advice, anti-fabrication) duplicate or pre-empt content the description itself defers to get_usage_guide, so not every sentence earns its token cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 34-parameter tool with no output schema, the description covers the orchestration-critical material: mandatory endpoint pairing, the coordinate fallback as the one worthwhile retry, hard-vs-soft filter semantics, output-interpretation traps (staySeated, ascentInMeters, bikeCarriageConditions, accessibility_routing no_data), and an explicit pointer to get_usage_guide. It is not a 5 because substantial behavior is deferred to that guide and there is no structured overview of responses or error/empty-result behavior beyond scattered hints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so per the baseline the description need not repeat parameter detail — and it mostly doesn't add meaning beyond it. It does emphasize cross-parameter rules (both endpoints mandatory, id-vs-coordinate exclusivity, filter grouping as "hart einschränkend"), but these largely restate the schema's own top-level and per-field descriptions. The added interpretation rules (cycling_profile→duration, staySeated counting) are output semantics rather than new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb, resource, and scope: "Plant ÖPNV-Verbindungen von A nach B, deutschlandweit, Fernrouten eingeschlossen" — planning transit connections nationwide, including long-distance routes. It then explicitly differentiates from the sibling show_connections by framing this tool as the data-oriented variant ("als Daten, für Ergebnisse, die du weiterverarbeitest") versus the "front entrance" for a human question, so an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when/when-not/tool-selection guidance: "Steht show_connections in deinem Werkzeug-Satz, ist das der Vordereingang für die Frage eines Menschen" names the alternative and the condition for choosing it instead, while the opening frames this tool as the choice when data needs further processing. It also instructs that answers must come from these tools rather than general knowledge and directs the agent to read get_usage_guide before filtering.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources