Skip to main content
Glama
mavrovde

ViaFrei

by mavrovde
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

get_departures

Read-onlyIdempotent

Check scheduled departures from any German public-transport stop—bus, tram, U-Bahn, S-Bahn, train, ferry—with line, destination, and platform. Use for next departures or future dates.

Instructions

Scheduled departures from any German public-transport stop — bus, tram, U-Bahn, S-Bahn, train, ferry — with line, destination, platform. Use when someone asks when a bus, tram, U-Bahn or ferry goes, or for another DAY or a clock time over 2 h away: "Wann fährt der nächste Bus ab Fulda Bahnhof?" Do NOT use for a railway station's trains now or later today — get_train_departures. Planned times only: for "is my bus late?" give the plan and say so; regional punctuality check_transit_disruption. No destination filter: read the board. Window 48 h, 15 per call. Results carry their attribution line.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
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 because it has a default — the default is only the fallback when the language is genuinely unclear, and an English question answered in German is 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 reach the far end of the 48 h timetable, 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. Changed2 schema fields changedv1.7.3
    • addedInput schema / properties / stop / maxLength
      Added value: +120
    • addedInput schema / properties / stop_id / maxLength
      Added value: +64
  2. Addedv1.4.9

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: planned times only (not live), no destination filtering, a 48 h window, a 15-row cap, and that results carry an attribution line. It does not state auth or rate-limit behavior, but for a read-only public-data lookup that is a minor gap.

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 the core purpose and mode list, then usage rules, then behavioral constraints — each sentence carries distinct information. It is dense and mixes German example phrases into an English description, which costs a little readability but not correctness.

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?

For a 7-parameter, no-output-schema lookup tool, the description covers purpose, routing to alternatives, result contents (line, destination, platform, attribution), result limits, and the planned-vs-live distinction. Nothing an agent needs to call it correctly is missing.

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% and the parameter descriptions are already unusually rich, so the baseline is 3. The description still adds value by stating the 48 h window, the 15-per-call cap, and the 'no destination filter — read the board' constraint, which shapes how the agent sets when/duration_min.

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 public-transport stop') and enumerates the covered modes, so the scope is unambiguous. It explicitly separates itself from the closest sibling, get_train_departures, which an agent could otherwise confuse it with.

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?

Gives explicit when-to-use triggers (any bus/tram/U-Bahn/ferry, another day, or a clock time over 2 h away), an explicit when-NOT-to-use rule routing railway station trains to get_train_departures, and a further alternative (check_transit_disruption) for punctuality questions. Nothing is left to inference.

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

Deploy Server

Other Tools