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

With no annotations provided, the description carries the full behavioral burden. It discloses what the tool returns (departure times, delays, platforms, at-platform status, cancellations), what it intentionally omits (arrival time), and its default behavior (La Hacquinière, direction Paris). It does not mention data freshness or output format, but the core behavior is well covered.

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 description is compact and front-loaded: it opens with what the tool does and the exact kind of information returned, then handles exclusions and usage context, and ends with defaults. Every sentence earns its place without unnecessary filler.

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, so the description needs to communicate return content; it does so by listing expected departure fields and explicitly excluding arrival time. It also covers defaults and fallback usage. A small gap is the lack of any statement about output structure or count behavior, but the description is largely sufficient for a real-time board 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 100%, so the schema already documents stop, count, and direction with defaults and enums. The description adds a default-stop reminder and direction default, but little new parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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 clearly identifies the tool as a real-time departure board for a stop, listing specific fields like expected time, delay, platform, at-platform status, and cancellations. It also explicitly distinguishes itself from next_trains_to_paris by stating it does NOT provide arrival times, which removes ambiguity between siblings.

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 gives concrete use cases: 'il est où le train ?', 'sur quelle voie ?', and as a fallback if the journey planner is down. It also explicitly routes the agent to next_trains_to_paris when arrival time is needed, providing clear when-to-use versus when-to-use-an-alternative guidance.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It usefully notes that no API key is required and that results are grouped by station, but it does not describe response format details, error behavior, or pagination. The description adds some behavioral value but leaves several operational details unstated.

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 description is three sentences long, front-loads the core purpose, and each sentence earns its place: what it does, when to use it, and what it does not do. There is no redundant or vague wording.

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 tool is simple, has only two parameters, and both are fully documented in the schema. The description covers the main use case, the alternative for addresses, and the nature of the returned data. It would benefit from a mention of the response shape or what happens when no stop is found, but it is complete enough for effective selection and invocation.

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 100%, so the baseline is 3. The description adds meaning beyond the schema by emphasizing that the query can be approximate and providing concrete examples like 'hacquini' and 'denfert'. This helps the agent understand the intended fuzzy matching behavior of the query parameter.

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 states a specific verb and resource: searching for an Île-de-France stop by name, returning identifier, lines, and modes grouped by station. It also distinguishes itself from plan_journey by clarifying that postal addresses are not handled here. This makes the tool's purpose immediately clear and differentiated.

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 explicitly says when to use this tool: when a stop name is unknown or when there is doubt. It also gives an exclusion case, postal addresses, and names the alternative tool, plan_journey, that should be used instead. This is strong routing guidance for an agent.

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?

Aucune annotation n'est fournie, donc la description doit porter la transparence comportementale. Elle précise le périmètre (perturbations en cours et à venir), ce qui est utile, mais elle ne décrit pas le format de retour, la fraîcheur des données, ni la couverture temporelle exacte (par exemple l'horizon des perturbations annoncées). C'est un niveau de transparence correct mais non exhaustif.

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?

La description est courte, en deux phrases, avec l'information principale en tête puis des exemples d'utilisation pertinents. Chaque phrase apporte une valeur ajoutée : la première définit le contenu, la seconde indique quand l'utiliser. Aucun mot superflu.

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?

Pour un outil simple avec un seul paramètre optionnel et aucune annotation, la description est globalement complète : elle précise le contenu, le périmètre temporel et les cas d'usage. Il manque juste une description plus explicite de ce que recevra l'agent (format de sortie), mais cela reste mineur au vu de la simplicité de l'outil.

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?

Le seul paramètre, include_past, est entièrement documenté dans le schéma (100 % de couverture). La description n'ajoute rien de spécifique sur ce paramètre, mais la mention des perturbations « en cours et à venir » sous-entend que le passé est exclu par défaut. Le schéma faisant déjà le travail, la note de base de 3 est appropriée.

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?

La description indique clairement l'objet de l'outil : l'état de la ligne RER B avec les perturbations en cours et à venir. Elle précise les types de perturbations (travaux, incidents, grèves, interruptions, suppressions), ce qui la distingue implicitement des outils de prochains départs ou d'itinéraires, même si elle n'emploie pas un verbe d'action explicite comme « retourner » ou « fournir ».

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?

La description donne des cas d'usage concrets et explicites : répondre à « il y a un problème sur la B ? » ou expliquer un trajet anormalement long. Elle ne mentionne toutefois pas explicitement quand ne pas utiliser cet outil par rapport aux outils frères, même si le contexte d'utilisation est suffisamment clair.

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?

With no annotations available, the description carries the full transparency burden and performs well: it discloses real-time behavior ('Temps réel'), delay reporting, exact output fields, and the RER B/no-shuttle-bus scope. It also explains that default stations are configuration-driven. For a read-only schedule lookup, there are no hidden side effects or auth requirements left undisclosed.

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 a compact set of sentences that front-loads the primary use case and then efficiently lists returned fields, scope restrictions, and default-station guidance. Every sentence contributes operational information with no redundancy or filler.

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 tool with four optional parameters, no output schema, and no annotations, the description provides the essential information: what is returned, real-time behavior, exclusions, and default handling. Count and when semantics are covered by the schema, so nothing critical an agent needs to select or invoke the tool correctly is missing.

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?

The input schema already documents all four optional parameters, so the baseline is 3. The description adds valuable guidance beyond the schema by stating that the default stations come from configuration and should only be overridden when the user mentions another station, which directly informs how the agent should populate from/to.

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 states exactly what the tool does: for each next train from La Hacquinière to Denfert-Rochereau it gives real departure time and delay, arrival time, duration, mission code, terminus, and disruptions. It also marks itself as the tool for the specific question 'quand est le prochain RER pour Paris et j'arrive à quelle heure?' and limits scope to RER B, distinguishing it from board or journey 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?

It explicitly identifies when to use the tool via the quoted user question and gives exclusions: RER B only and no shuttle buses. It also instructs that default stations come from configuration and should only be specified when the user mentions another station. However, it does not explicitly name sibling tools such as departures_board or plan_journey as alternatives, so some disambiguation remains implicit.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that results are real-time, multimodal, include connections, and that endpoints accept postal addresses directly without requiring nearest-stop lookup. It does not cover response format or rate limits, but those are not critical for this routing use case.

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?

Three sentences, each earning its place: the core scope, the key address-input behavior, and the sibling routing preference. It is front-loaded and contains no redundant filler.

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 description covers scope, input flexibility, arrival-time handling, and the main alternative, which is enough for common calls. Since there is no output schema and no annotations, it could have briefly described the returned itinerary shape, but the core invocation context is complete.

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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving a concrete address example and by connecting user intent ('je dois être à X à 9 h') to the when/arrive_by combination, which is a helpful semantic bridge not explicitly in the 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 description states a clear function: real-time itinerary computation in Île-de-France, with all modes and connections included. It differentiates itself from siblings by emphasizing multimodal routing and explicitly names next_trains_to_paris as the alternative for a specific commute case.

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?

It gives an explicit routing rule: prefer next_trains_to_paris for habitual home → Paris trips. It also translates a natural-language arrival requirement ('je dois être à X à 9 h') into the correct parameter usage, which helps an agent select and invoke the tool correctly.

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