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

Annotations cover only the safety profile (readOnly, idempotent, non-destructive), while the description discloses genuinely non-obvious behavior: matching order (exact, then prefix, then contained words), multi-piece OSM pistes counting as one, lift endpoints resolving to top vs bottom station, candidate lists on ambiguity, and the 5 km coordinate rejection rule.

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 dense paragraph of roughly 110 words, front-loaded with what the tool does before the rule details. Every clause carries substantive semantics, though the compound sentences on lift resolution and level filtering are somewhat hard to scan.

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 routing tool with no output schema, the description supplies most of what an agent needs to call it correctly, including failure modes and ambiguity handling. It stops short of describing the returned route (geometry, distance, elevation) and omits the avoid_closed parameter's behavior.

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 carry all parameter meaning, and it does so well for from/to (name matching, lift top/bottom resolution), resort (coordinate proximity limit) and level (terrain-avoidance semantics, expert as the only level permitting freeride/extreme). It never explains the avoid_closed parameter or its default, leaving one of five params undocumented.

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 ('Route between') and concrete resources (named pistes, lifts, resort base, lat/long coordinates) powered by mapped OSM data. No sibling tool performs routing, so the function is unambiguously distinct from the informational tools in the sibling list.

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?

Gives clear operational context: name matching is accent-insensitive and partial, ambiguity returns candidates, and out-of-resort coordinates are rejected, which tells the agent when the call will fail. It never states an explicit 'use this rather than X' alternative, though no sibling offers routing, so nothing critical is missing.

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