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

Annotations already declare readOnly, idempotent, non-destructive behaviour, and the description adds real operational context on top: per-call request accounting ('Each call counts as one request of the plan, a cut one too'), timeout capping at 120 s, truncation at max_chars with offset continuation, plan gating of the date filter, and attribution/licence terms. That is exactly the extra context annotations cannot carry.

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 statement and return behaviour are front-loaded, and the pattern list is dense but each line encodes a distinct query idiom that is otherwise hard to infer. It is long, and a few patterns ('Lines with coordinates: out geom; (large)') are terser than the rest, but no sentence is filler.

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 no output schema, the description still explains the response shape ('starts with counts and the date of the data, then one JSON object per element and line'), pagination behaviour, and data provenance. For a free-form query tool of this complexity, an agent has everything needed to call it correctly and to react to a truncated answer.

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 100%, so the baseline is 3, but the description adds meaning beyond it by explaining how max_chars and offset interact ('The answer ... up to max_chars characters. When it is cut, call again with offset') and by tying [timeout:N] to a hard 120 s ceiling. add_elevation is left entirely to the schema, which keeps it from a 5.

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 ('Runs an Overpass QL query on the full OpenStreetMap planet at overpass.ch') plus what comes back ('nodes, ways and relations with their tags'). This clearly separates it from siblings like geocode, reverse_geocode and elevation, which do lookup-style work rather than arbitrary spatial queries.

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 patterns block gives concrete when-to-use-which-form guidance (box, around radius, area, name, count, tags, geom, regex, id) and notes plan restrictions for the date filter. It never explicitly routes to the sibling overpass_examples for query authoring, which is the one obvious gap.

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