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

Annotations already establish read-only, idempotent safety, and the description adds substantial context on top: hub-based routing within 1.5 km, straight-line estimation flagged with estimate: true, null minutes with reason codes 'outside-london'/'outside-coverage', and capping at 120 minutes with capped: true. These are exactly the non-obvious behaviors an agent needs before interpreting results.

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 core fact is front-loaded, and nearly every clause carries real information. But it is delivered as one sprawling sentence with nested parentheticals and an ellipsis, making the edge-case rules hard to parse rather than separating them into scannable statements.

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?

Given an output schema exists, the description needn't explain return shapes, yet it still documents the sentinel fields (estimate, capped, reason) that the schema won't convey semantically. Combined with the London-only routing constraint, an agent has everything needed to call this correctly and read the results honestly.

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 area_id, places, and every mode/category nuance. The description adds only that results are per-place with a range and that car means typical morning traffic with no parking — a point the schema also makes. 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?

States a specific verb and resource with precise scope: door-to-door minutes from one neighbourhood to a set of places, on a weekday morning, across four modes. This is unmistakably different from metric-reading siblings like get_area_metric or find_areas, which the agent can rule out 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?

The description gives useful operating conditions (hub routing, straight-line fallback, outside-London and outside-coverage cases, 120-minute cap), effectively telling the agent when results will be degraded. However, it never names an alternative tool or states when to prefer a different call, so guidance is implied rather than explicit.

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