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

The description goes beyond the structured fields by explicitly listing the behavioral traits of the output: 'Shows line, destination, minutes to wait, delay and platform.' This provides valuable data context missing from the schema.

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?

The definition is highly efficient and front-loaded, though the argument definition section is a standard listing rather than prose flow.

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?

The definition is highly complete, detailing the expected inputs (IDs vs. names) and the specific attributes returned (line, delay, platform), making it robust for complex real-time queries.

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 0% schema description coverage, the description must be comprehensive. It provides critical context that the stop_id can be a formal ID (e.g. 'stop_area:IDFM:63244') or a 'plain station name,' resolving ambiguity for the agent.

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 purpose is crystal clear, stating the tool gets 'next real-time departures at a station' and using specific questions (e.g., 'When is the next RER B?') to define its scope clearly against journey planning tools.

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?

The description provides explicit usage patterns and examples, showing agents exactly what kind of queries this tool is intended to resolve versus general travel inquiries.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description adds genuinely useful disclosure: at most 3 options returned, the shape of each option (duration, transfers, step list) and that departure_time defaults to now in Paris local time. It says nothing about real-time versus scheduled data, ambiguous place-name handling, or error behavior.

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?

Front-loaded with what the tool does, then when to use it, then what it returns, then the arguments — a logical order with no filler sentences. The example values inside the Args block are doing real work rather than padding.

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?

For a three-parameter tool with no output schema, the description covers inputs, defaults and the return shape, so an agent can call it confidently. The gap is behavioral edge cases: routing ambiguity resolution, real-time versus timetable data, and how it relates to the disruption sibling.

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 0%, so the description carries the whole burden and does so well: from_place is defined as station name, address, landmark or a stop ID from search_stop, with examples; to_place inherits those formats; departure_time is documented as optional with both accepted formats and a 'defaults to now' rule. That fully compensates for the empty schema.

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 opening sentence names a specific verb and resource ('Plan a public transport journey') and pins the geographic scope to Île-de-France. That is enough to separate it from siblings like search_stop, next_departures and traffic_disruptions without opening any schema.

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?

Real user phrasings ('How do I get from X to Y?', 'Fastest way to Orly from Bastille at 18:00?') make the intended trigger concrete. It stops short of naming alternatives — nothing says to use next_departures for a single stop's real-time board or traffic_disruptions for network status — so there is no explicit exclusion rule.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond that — a capped result set of 'up to 5 matches with the lines serving each one' — but says nothing about behavior when zero matches are found or how ambiguous partial names are resolved, which is the main risk for a name-search tool.

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?

The intent and timing are front-loaded in the first two sentences, which is the right ordering. The trailing 'Args:' block partly repeats the station examples already given in the body ('Gentilly' appears twice), which is mild waste for a one-parameter tool.

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?

For a single-parameter tool with no output schema, the definition covers what it does, when to call it, and roughly what comes back (up to 5 matches plus their lines). The notable omission is the no-match / ambiguity case, though the small surface area limits how much damage that causes.

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 0% — the schema only says 'Query: string' — so the description carries the burden and does add real meaning: the value is a station or stop name, accepted in French or English spelling, with worked examples ('Gentilly', 'Châtelet', 'Gare de Lyon'). It does not address partial matches or accents, but the core semantics are supplied.

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 and resource ('Find Paris / Île-de-France stations and stops by name and return their IDs') and scopes it geographically. It also ties itself to a sibling by naming next_departures as the consumer of the returned IDs, so an agent can separate it from the other tools without opening a schema.

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?

'Use this first when the user names a station... and you need its ID for next_departures' gives clear triggering context and a downstream dependency. It stops short of explicit exclusions — nothing says when to skip this in favor of plan_journey or traffic_disruptions, which matters since those siblings also take station input.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the description only needs to add context — and it does: results include both active and planned disruptions, are ordered most-severe-first, and elevator/escalator outages are counted but not listed. That last caveat is genuinely useful because it pre-empts an agent assuming a complete outage picture.

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?

Purpose and usage examples are front-loaded, and the args block is compact. The example questions are somewhat repetitive with the opening sentence, but each still earns its place as a concrete trigger, so there is little waste.

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?

For a one-optional-parameter read tool with no output schema, the definition covers purpose, trigger examples, identifier format, default behavior, result ordering, and a content caveat. An agent has everything it needs to decide to call it and to construct a valid argument.

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 0%, so the description must carry the whole burden for the single optional 'line' parameter, and it does: it supplies the canonical naming convention with four examples ('Metro 7', 'RER B', 'Tram T2', 'Transilien L') and defines the null/default behavior as a network-wide summary. This removes the main failure mode of a free-text line identifier.

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 opens with a specific verb and resource — 'Get current traffic disruptions, incidents and works on the Île-de-France network' — plus a stated scope (active and planned). That is far more precise than the bare name 'traffic_disruptions', but it never names or contrasts the siblings (search_stop, next_departures, plan_journey), so an agent must infer the boundary 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?

Three concrete example questions ('Are there problems on Metro 7?', 'Is the RER A running?', 'Any disruptions right now?') give a clear trigger context, and the args block states that leaving 'line' empty yields a network-wide summary. What is missing is any when-not guidance, e.g. that live departure times belong to next_departures or routing to plan_journey.

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