Skip to main content
Glama

MobilityMCP

by eu.projektionisten
OverviewDiscussionsAdmin

show_departures

Read-only

Der Vordereingang für jede Abfahrtsfrage eines Menschen: liest die Tafel einer Haltestelle wie departures und liefert sie zusätzlich als Ansicht aus, die ein Wirt mit Ansichten dem Nutzer zeigt — je Abfahrt Linie, Ziel, Gleis/Steig, Zeit und Echtzeit-Lage. Beantwortest du einem Menschen eine Abfahrtsfrage, ruf dies statt departures, das für Ergebnisse ist, die du weiterverarbeitest. Pflicht ist die Halte-Id, wie dort: id — eine Id aus resolve_location, kein Haltestellen-Name; render_payload entfällt. Der Antwort-Text ist der von departures; die Rohdaten daneben tragen nur die Felder, die die Ansicht zeichnet. Anleitung: get_usage_guide mit tool='departures'. Anti-Fab: Linien, Ziele, Zeiten und Gleise ausschließlich aus dem Output dieses Aufrufs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesStop id to read the board of, as a DHID (`"de:03241:57"`). Resolve the stop first — a name here is an argument error.
timeNoISO 8601 timestamp (e.g. `"2026-06-15T08:30:00Z"`). Omit for now. Resolve a spoken time with the time tool rather than computing one.
limitNoMaximum number of departures, at least 1. Default 5, values above 15 are served as 15.
modesNoTransport-mode filter; the board then shows nothing else. Entries: `"bus"`, `"tram"`, `"subway"`, `"train"`/`"rail"`, `"ferry"`, `"transit"`; several combine. Another entry — a street mode, a misspelling — is an argument error, not a dropped filter: a board lists scheduled services. Omitted or empty = all modes. A Stadtbahn or light-rail mention needs BOTH labels — `["tram","subway"]`: which of the two such a network carries depends on the dataset rather than on the vehicle. Set the filter only when the user really asks for a vehicle type; the guide has the rest of the vocabulary and the traps.
formatNoAnswer serialisation: `"toon"` (default) or `"json"` — the detail is in `get_usage_guide`. **An agent leaves this out.**
extendedNo`true` keeps the map data in the text: every stop's coordinate, the whole course of each run, and a polyline where the board carries one — for an application that DRAWS the board. It multiplies the answer. A chat client leaves it off.
directionNoName of a stop the user wants to head TOWARD („Richtung Wettbergen") — not a routing destination. The board keeps only departures heading that way, whether the named stop is the terminus or a stop downstream of the queried one. Matching is case-insensitive and area-prefix-tolerant.
verbosityNoHow much of each departure comes back: `"compact"` (default — everything an answer is cited from) or `"full"` (adds the onward stops of the run, and with them the per-stop cancellation marker). A third word is an argument error, not the default.
last_of_windowNoWhich end of a `time_range_seconds` window to read: omitted or `false` the FIRST departures, `true` the LAST ones (the end-of-service question). An answer carrying `window_truncated: true` beside its board did NOT reach the window's end — its last entry is then not the last departure. Without a window it has no effect.
target_bearingNoTarget bearing in degrees (0=N, 90=E, 180=S, 270=W) for a SOFT direction („Richtung Norden", „Richtung Stadt") instead of a stop name. The board keeps only departures whose course lies within `bearing_tolerance` of it. Mutually exclusive with `direction`.
is_arrival_timeNo`true` reads `time` as an ARRIVAL time — the same as `arrival_departure = "arrivals"`.
arrival_departureNo`"arrivals"` (when vehicles reach `id`) or `"departures"` (default) — a third value is an argument error. Wins over `is_arrival_time` when both are set.
bearing_toleranceNoAngular tolerance in degrees for `target_bearing`. Default ±60°.
time_range_secondsNoTime WINDOW in seconds, starting at `time`. Together with `last_of_window` this answers „letzte Fahrt": pick it so the window ENDS after end of service (from the evening on, `28800` = 8 h rather than 4 h). Omit for a normal next-N lookup.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare the tool read-only and non-destructive, and the description adds meaningful behavioral detail on top: the answer text is identical to `departures`, while the raw data carry only the fields the view draws. It also adds an explicit anti-fabrication instruction to source line, destination, time, and track information exclusively from the call output. No contradiction with the annotations exists.

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?

The description is front-loaded with purpose and usage and uses bold labels to separate scope, required input, instructions, and the anti-fabrication rule. It is somewhat dense, and the 'Wirt mit Ansichten' metaphor may be slightly confusing, but for a 14-parameter tool each section earns its place.

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 complex tool with 14 parameters and no output schema, the description supplies the essential missing context: when to choose it over `departures`, required id provenance, the return shape (same answer text as `departures`, raw data limited to view-drawn fields), and where to find more details. The schema covers the parameters, while the description covers selection and output behavior, making it sufficiently complete.

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% and the input schema thoroughly documents all 14 parameters, so the baseline is 3. The description reinforces the critical required `id` semantics (`id` from `resolve_location`, not a stop name) and notes that `render_payload` is absent, but it adds little beyond what the schema already provides.

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 opens by identifying the tool as the 'front entrance' for human departure questions and states it reads a stop's board like `departures` and renders it as a view, listing line, destination, platform, time, and real-time status. It explicitly distinguishes itself from the sibling `departures`: call this when answering a human, not when processing results. That is a specific verb plus resource with clear sibling differentiation.

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 explicitly says 'Beantwortest du einem Menschen eine Abfahrtsfrage, ruf dies statt departures' and clarifies that `departures` is for results you process further. It also states that the required stop id must come from `resolve_location`, not a stop name, and points to `get_usage_guide` with `tool='departures'`. This gives concrete when-to-use and when-not-to-use guidance.

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

All MobilityMCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources