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

Annotations already declare readOnlyHint=true, and the description aligns by framing the operation as an estimate. It adds context beyond the annotation by enumerating what the estimate includes (loc_id count, shape/vintage availability, bytes, delivery mode, citation requirements, charge units) and by clarifying that it is not a canonical release bundle. This provides meaningful behavioral transparency without contradicting annotations.

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 description is two sentences, front-loaded with the core action ('Dry-run estimate') and packed with specific output details. Every clause adds value, with no redundancy or 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?

The tool has 7 parameters and a nested object, but the schema handles parameter detail well. With no output schema, the description compensates by listing exactly what the estimate covers. It also clarifies the artifact boundary (not a canonical bundle). The only minor gap is not explicitly mentioning the three mutually exclusive input selectors (loc_id, loc_ids, scope), but the schema's anyOf provides that context.

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 86%, so the schema already explains most parameters. The description adds no additional parameter details; it only names the tool's purpose. Baseline of 3 is appropriate because structured data carries the semantic load, and the description does not need to compensate.

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 verb ('estimate') and resource ('geometry export'), and clearly distinguishes this from actual creation by calling it a 'dry-run'. It also explicitly differentiates from 'canonical DaedalMap geometry release bundle', setting it apart from sibling tools like get_geometry and create_geometry_export.

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 'dry-run estimate' phrasing implies this tool is used before a real export, but the description does not explicitly state when to use it versus create_geometry_export or other alternatives. No exclusions or alternative tool names are provided, leaving usage to be inferred rather than directed.

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