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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: the response shape (category, coordinates, visit minutes, one-line description) and an explicit warning that setting detail to "full" yields a large response—valuable for a read tool whose main behavior risk is response size.

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, front-loaded with the resource and its contents, then the detail/full caveat. No filler, and the response-size warning is placed where it will be read before the call.

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 carries the return-shape burden and does so by enumerating the guide's sections and sight fields. Annotations cover the safety profile. Minor gaps: it doesn't mention the language parameter's effect on returned names/descriptions, but that is documented in the schema, so nothing critical is missing.

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 67%; city_id and language are documented in the schema, but the `detail` enum has no description there. The description fills that gap precisely, explaining that "full" adds the long description of every sight and produces a large response, which the schema alone does not convey.

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 exactly what the tool retrieves (one city's guide) and enumerates the contents: overview, headline sights, lesser-known sights, and every sight with category, coordinates, visit minutes and a one-line description. That's a specific verb+resource with enough detail to separate it from get_attraction or compare_cities, 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 only usage instruction is 'Set detail to "full"... (large response)', which is parameter guidance rather than when-to-use guidance. There's no statement like 'use this for a full city overview, use get_attraction for a single sight' and no prerequisites (e.g. getting city_id from search_cities is only in the schema). Usage is implied by the content list.

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