Departures

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

Annotations already declare readOnlyHint and openWorldHint, so safety and network behavior are covered. The description adds meaningful content context beyond that: the board is live and includes delays, platform changes, cancellations and free-text messages, which tells the agent what to expect in the response. It does not mention failure behavior for unknown stations, which is the remaining gap.

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

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

A single tight sentence with no filler, front-loading the resource and then listing the contents. Nothing is redundant with the title or schema.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. What is missing is any routing hint to 'find_station' for an unresolvable station name and any note about the one undocumented parameter, so it falls just short of fully complete for a 4-parameter tool.

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

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

Schema description coverage is 75% and the schema documents 'hours', 'start' (Berlin local time, ISO) and 'station' formats. The description adds no parameter-level meaning at all, notably nothing about the undocumented 'limit' or the interaction between 'hours' and 'start'. Baseline 3 is appropriate given the schema does most of the work.

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

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

The description names a specific resource (departure board) and enumerates the payload contents (live delays, platform changes, cancellations, messages), so an agent can tell what data it returns. It does not explicitly contrast itself with the sibling 'arrivals' or 'find_station', relying on the tool name alone for that distinction.

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

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

There is no statement of when to use this tool versus 'arrivals' (same station, opposite direction) or 'find_station' (for resolving a station name or EVA number). Usage is only implied by the name and the required 'station' parameter.

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