Skip to main content
Glama

show_connections

Read-only

Der Vordereingang für jede Verbindungsfrage eines Menschen, auch wenn er nur nach Zeiten fragt: plant die Fahrt wie connections und liefert sie zusätzlich als Ansicht aus, die ein Wirt mit Ansichten dem Nutzer zeigt — je Verbindung eine Karte mit Zeiten, Dauer, Umstiegen und Echtzeit-Lage. Beantwortest du einem Menschen eine Verbindungsfrage, ruf dies statt connections, das für Ergebnisse ist, die du weiterverarbeitest. Pflicht sind BEIDE Endpunkte, wie dort: origin_id UND destination_id — oder die vier Koordinaten-Felder; render_payload entfällt. Der Antwort-Text ist der von connections; die Rohdaten daneben tragen nur die Felder, die die Ansicht zeichnet, ihr Kartenverlauf davon im _meta. Anleitung: get_usage_guide mit tool='connections'. Anti-Fab: Linien, Zeiten, Halte 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`.
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.6/5.0
Behavior4/5

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

Annotations cover the safe read-only profile (readOnlyHint=true, destructiveHint=false), and the description adds real behavioral detail: the response text matches `connections`, the raw data carries only view-drawing fields, and the map route is placed in `_meta`. It omits any discussion of error or empty-result behavior, but no output schema exists and the core non-obvious behavior is disclosed.

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

Conciseness5/5

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

The description is compact despite the tool's 33-parameter surface: four bolded sentences covering purpose, routing, required endpoints, output shape, guide pointer, and anti-hallucination rule. It is front-loaded with the core decision and every sentence earns its place.

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 complex tool with no output schema, the description gives enough orientation: it explains what the rendered result contains, what the response text is, which endpoint pair is mandatory, and directs to `get_usage_guide` for parameter-level traps. It could be slightly more explicit about how `show_connections_slim` fits in, but that gap is covered by the usage guide link.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful constraint beyond the schema: both `origin_id` and `destination_id` are required together, or alternatively all four coordinate fields, and `render_payload` is not to be passed. This is especially valuable because the schema lists no required parameters.

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 description names a specific verb and resource: it is the front door for every human-facing connection question, plans like `connections`, and adds a rendered view with cards showing times, duration, transfers and real-time position. It also explicitly contrasts itself with `connections` (result for further processing), so it is immediately distinguishable from the closest sibling.

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?

It gives an explicit when-to-use rule: answer a human connection question by calling this instead of `connections`, which is for machine-processing. It also states the mandatory origin/destination endpoints or coordinate fields and points to `get_usage_guide` with `tool='connections'` for full instructions.

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