Skip to main content
Glama

get_departures

Read-onlyIdempotent

Scheduled departures from any German stop — bus, tram, U-/S-Bahn, train, ferry — or the nearest stops around a place ("Abfahrten in der Nähe"). Use when asked when a bus, tram, U-/Stadtbahn or ferry goes ("welche Bahnen" at a Hbf too), or for another DAY or a time over 2 h away: "Wann fährt der nächste Bus ab Fulda Bahnhof?" Do NOT use for a rail station's trains today: get_train_departures. Plan times with live delay/cancellation where held; punctuality: check_transit_disruption. No A-to-B journeys: say so, no call. Holds ≥ 48 h ahead, ≤ 3 days. 15 per call. Show the attribution line.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude in WGS 84, e.g. 50.551 — with lon, the nearest stops around a point the caller already holds. Use place for a named place.
lonNoLongitude in WGS 84, e.g. 9.676. Use with lat.
stopNoThe stop, as the person says it: "Fulda, Bahnhof", "München, Marienplatz", "Köln, Hbf", "Hamburg, Rathausmarkt" (town first). Include the town when the person did — half the names in Germany exist in twenty towns, and a bare "Bahnhof" or "Hauptbahnhof" comes back as a list of candidates to choose from, so call it and let the result ask. Pass their words; do not guess an id. Give either stop OR the stop id, never both.
whenNoStart of the window as an ISO-8601 instant with an offset ("2026-10-02T07:30:00+02:00"). Leave it out for "now". Convert the person's words yourself — "morgen früh", "tonight" — and pass the instant; the answer is always rendered in Europe/Berlin.
limitNoHow many departures to return, earliest first (1–15, default 10). The result always says how many more were in the window.
modesNoKeep only these kinds of service: "bus", "tram", "subway" (U-Bahn), "rail" (every train, including S-Bahn and regional) or "ferry". Omit it unless the person named a kind — "nur Busse", "welche Tram". Several are allowed, which is what "die Busse und Bahnen vor dem Hbf" means. An S-Bahn is "rail": the feed does not always distinguish it, and the line name ("S 6") says which it is.
placeNoA place to list the nearest stops around, when the person names no one stop: a town, district or address ("Bahnhofstraße 12, Fulda", "Köln-Ehrenfeld"). Lists the nearest stops within 5 km with their next departures, as viafrei.de's place page does. Give exactly one of stop, stop_id, place or lat+lon.
stop_idNoThe stop's timetable id, exactly as a previous result of this tool gave it ("de:06631:1234"). It skips the name lookup and is exact — use it for a follow-up about a stop this tool has already named, and for one the person picked out of a candidate list.
languageNoSet this on every call to the language the person is writing in: "en" if they wrote English, "de" if they wrote German. Do not leave it out: it defaults to German ("de"), which is only the fallback when the language is genuinely unclear, so an English question sent without it is answered in German — a wrong answer. Place names, station names and road numbers are never translated in either language; in English the German term is kept in parentheses so the person recognises it on signs and in local apps.de
duration_minNoHow far past that moment to look, in minutes (5–1440, default 60). Small for "what goes now", a few hours for an evening. To look further ahead (the timetable reaches at least 48 h), move `when` instead of widening this: a window of a whole day returns at most 15 rows and would answer about the wrong half of it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / lat
      Added value: +{
      +  "description": "Latitude in WGS 84, e.g. 50.551 — with lon, the nearest stops around a point the caller already holds. Use place for a named place.",
      +  "maximum": 90,
      +  "minimum": -90,
      +  "type": "number"
      +}
    • addedInput schema / properties / lon
      Added value: +{
      +  "description": "Longitude in WGS 84, e.g. 9.676. Use with lat.",
      +  "maximum": 180,
      +  "minimum": -180,
      +  "type": "number"
      +}
    • addedInput schema / properties / place
      Added value: +{
      +  "description": "A place to list the nearest stops around, when the person names no one stop: a town, district or address (\"Bahnhofstraße 12, Fulda\", \"Köln-Ehrenfeld\"). Lists the nearest stops within 5 km with their next departures, as viafrei.de's place page does. Give exactly one of stop, stop_id, place or lat+lon.",
      +  "maxLength": 120,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive. The description adds valuable context beyond that: coverage window (≥48 h ahead, ≤3 days), result cap (15 per call), attribution requirement ('Show the attribution line'), and directs delay/punctuality checks elsewhere. It does not cover error behavior or return format, so not a full 5.

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

Conciseness4/5

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

Front-loaded with purpose, then usage and constraints. The description is information-dense and every sentence contributes, but it is quite long and telegraphic in places (e.g., 'Holds ≥ 48 h ahead, ≤ 3 days. 15 per call. Show the attribution line.'), which slightly reduces scannability.

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

Completeness5/5

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

Given the tool's complexity (10 parameters, multiple input modes, open-world stop data) and the absence of an output schema, the description covers routing, coverage limits, attribution, and sibling alternatives. An agent has enough to invoke correctly without reading external docs.

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 the schema already documents all 10 parameters in detail (including examples and constraints). The description adds no additional parameter-specific meaning beyond what the schema provides; baseline 3 is appropriate when the schema carries the full parameter burden.

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?

States a specific verb and resource: 'Scheduled departures from any German stop' and enumerates the modes (bus, tram, U-/S-Bahn, train, ferry). Immediately distinguishes itself from the sibling get_train_departures by excluding a rail station's trains today.

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?

Explicitly names when to use (when asked when a bus/tram/U-Bahn/ferry goes, for another day or time >2 h away, for nearest stops around a place) and when not to (rail station's trains today → get_train_departures; punctuality → check_transit_disruption; A-to-B journeys → no call). Provides concrete German example phrases.

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