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

Annotations already establish that this is a read-only, idempotent, non-destructive lookup. The description adds valuable behavior beyond annotations: it lists the returned fields, explains the 200-region pagination, and clarifies that a query miss means the map truly lacks that region.

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 front-loaded with the return shape and page size, then moves naturally into usage guidance and parameter behavior. Every sentence contributes distinct information without redundancy.

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?

For a read-only lookup with full schema coverage and no output schema, the description supplies enough return detail, pagination behavior, and usage guidance for correct invocation. No important behavioral or contextual gap remains.

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. The description adds useful meaning beyond the schema by explaining that query searches keys, titles, and aliases and that no hits is a definitive absence, and by directing use of offset for further pages.

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 and resource: 'Look up one map' and returns its regions. It also names the returned fields and pagination size, making the tool's purpose distinct from list_maps and render_map.

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 explicitly says this is rarely needed before rendering and names render_map as the alternative that accepts names, codes, and aliases. It then gives concrete use cases: building a complete dataset, learning region naming, or resolving a key render_map could not match.

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