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

Goes well beyond the annotations: discloses that the site numbers are 'OURS, not the provider's,' that every sheet carries an image_url usable in any client, that the tool cannot report whether the client displayed the image, and that absence of a map resolves to an explicit statement rather than a failure. These are exactly the operational traits annotations cannot express.

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?

Front-loads the core output (image + coordinates) in the first sentence, which is the right structure. The body is long and mildly repetitive across five paragraphs, but nearly every sentence carries operational substance (naming convention, image fallback, absence handling), so little is pure padding.

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 no prose. The description still covers the hard edges an agent needs — our-not-provider numbering, client display uncertainty, image_url fallback, and non-fatal absence — leaving no material gap for a 4-parameter read tool.

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%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining the zone_id vs campground_id interaction ('Where a campground ships one sheet for all its zones, that sheet is returned for any zone within it'), which the schema does not state, and reinforces the round-trip workflow for highlight_site_ids.

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 — returns the drawn site map as an IMAGE plus the pixel position of every site — and immediately distinguishes it from the row-oriented sibling list_zone_sites. An agent can tell exactly what this returns versus what the row data gives.

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?

Explicitly frames the use case as 'questions the rows cannot answer in words: which sites sit by the water, at the end of a loop, away from the road,' names the alternative (list_zone_sites with real lat/lng for geographic inventories), and points to has_map on list_campground_zones for pre-flight checks. When-to-use, when-not, and the alternative are all present.

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