Listar recorridos

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context—no mention of what the list returns, pagination, ordering, or volume of results. With annotations present the bar is lower, so the minimal-but-consistent picture earns a midpoint score.

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?

Single sentence, front-loaded purpose, zero waste. It efficiently communicates the core operation and the filter option. One could argue it's slightly under-specified rather than concise, but for the information it conveys, the structure is appropriate.

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?

This is a simple filtered-list tool with an output schema present, so the description doesn't need to explain return values. The output schema and one clearly documented parameter cover much of the need. However, given that the mode parameter is undocumented in the schema (0% coverage), the description could have more thoroughly covered its valid values and semantics, which it does enumerate partially.

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 only 1 parameter at 0% schema description coverage, the description carries the burden of defining 'mode'. It does list valid mode values (bus, metro, rail, tram), which adds value beyond the schema that just declares mode as a string/null. However, it doesn't specify whether the parameter is case-sensitive, accepts aliases, or what happens if omitted.

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 the verb+resource clearly ('Listar recorridos' = list routes) and distinguishes itself from route-specific siblings by presenting a list operation. However, it doesn't differentiate from other list-like siblings semantically beyond naming the resource. The 'opcionalmente filtrados por modo' adds scoping but the tool name and title already communicate the core purpose.

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 implies when to use this tool (when listing routes, optionally by mode) but gives no explicit usage guidance or exclusions relative to sibling tools like get_route, get_route_stops, or get_route_shape. No when-not-to-use or alternative tool references are provided, so the agent must infer appropriate usage.

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