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

No annotations are provided, so the description carries the full disclosure burden. It does describe the return content (published facts with source and date, stations in order), which implies a read-only lookup, but says nothing about auth requirements, behavior on an unknown id, or whether facts can be missing.

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 front-loaded sentence that names the resource first and then the returned payload. The parenthetical enumeration is dense but every item adds disambiguating value, so there is no wasted text.

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?

There is no output schema and no annotations, so the description has to describe returns — and it does, listing the fact categories, provenance (source and date), and ordered stations. Only error/missing-data behavior and id format are left unstated, which is a minor gap for a simple read 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?

With one parameter (id) at 0% schema description coverage, the description must compensate. It implies the id identifies a single line, but never states the id format or where to obtain it (e.g., from list_lines), leaving the parameter only partially explained.

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?

States a specific verb ('get') and resource ('one night train line'), and enumerates the fact types returned (power sockets, bikes, pets, food, booking window) plus stations in order. It implicitly contrasts with list_lines by specifying a single line, but never explicitly names a sibling to distinguish itself.

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 explicit guidance on when to use this versus alternatives such as list_lines, get_station, or facts_by_key. Retrieval by a single line id is only implied by the phrasing 'one night train line', with no stated preconditions or exclusions.

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