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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that results are the *nearest* routes constrained to a 4.5–5.5 km band, implying distance ordering, but says nothing about what happens when no route qualifies or how the default result count behaves. Useful context, but thin beyond what annotations provide.

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 short sentences, front-loaded with the core scope and the numeric band before the example phrasing. The closing 'a 5k near me' line largely echoes the tool title, so it is slightly redundant but still reinforces intent cheaply.

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?

With only 4 flat parameters and no output schema, the description needs to convey the search scope and result character; it does both by naming the 4.5–5.5 km band and the 'nearest' ordering. Missing detail on empty-result behavior and the limit default keeps it just short of 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 75% — lat, lng and max_distance_from_user_km are already documented in the schema. The description adds the 4.5–5.5 km filtering semantics that no parameter declares, but leaves 'limit' (default 8, max 15) entirely unexplained. Baseline 3 is appropriate given the schema does most of the work.

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 gives a specific verb and resource ('Find Skamper running routes') plus a precise scope: routes 'close to 5 km (parkrun distance)' and 'between 4.5 and 5.5 km'. That tolerance band alone separates it from generic siblings like search_routes or browse_runlists without needing them named.

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 supplies a concrete use context — 'Great for runners asking "a 5k near me"' — which tells the agent when this specialized tool beats a general route search. It stops short of naming an alternative or stating when not to use it (e.g. for 10k or arbitrary distances), so it is clear context without exclusions.

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