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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without description help. The description adds useful context beyond that: it discloses the return shape (one polygon per contour with geodesic area) and the data source (Valhalla/OSM), which matters for trusting the results. It does not mention external-service dependence risks, contour-count limits, or performance characteristics, so it is additive but not rich.

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?

Two sentences, both front-loaded: the question frames the capability first and the return format follows. No filler, no repetition of the title. Slightly tighter would be stating the output before the question, but the structure is efficient.

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?

An output schema exists, so return values need not be explained in prose, and the annotations carry the full safety profile. The description covers what the tool produces and where the data comes from. The only real gap is routing guidance against travel_time_matrix and route, which is a usage-guideline issue rather than a missing 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?

Schema description coverage is 100%, with every parameter documented including the mode enum, the 1-60 minute range, the 4-item contour cap, and WGS84 coordinate bounds. The description only restates the three travel modes already listed in the enum. With the schema doing all the work, the baseline 3 applies.

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 capability in concrete terms: reachable-area polygons from a point within N minutes by walk, bike, or car, and it names the underlying engine (Valhalla over OpenStreetMap). The agent can tell this is an area-generation tool rather than a point-to-point tool like route or travel_time_matrix, though no sibling is named explicitly.

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 question framing implies a use case ('where can you get to from a point'), but there is no explicit when-to-use or when-not-to-use guidance. Nothing distinguishes it from travel_time_matrix (times between points) or route (path geometry), which are the closest siblings and the most likely source of mis-selection.

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