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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuinely useful context beyond that: known coordinates are required (no geocoding is performed), the response includes a coverage register plus UI, and a registered source is explicitly not proof of coverage or absence of risk. It does not describe pagination or register size, but the caveat and preconditions are substantive.

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 purpose is front-loaded and the chaining note is well placed at the end, but the middle is dense with abstract phrasing ("community geometry, configuration and document references from unassessed local zoning, parcel intersections and statutory applicability") that costs more than it conveys. The disclaimer sentence is useful but adds to the bulk.

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 an output schema present, return-value documentation is optional, yet the description still signals the shape (coverage register plus Atlas UI) and adds the critical site_ref chaining contract. The main remaining gap is that an agent cannot tell what a "registered context/place route" concretely is or how a partially-covered location is represented, but for a read-only pre-flight check this is close to complete.

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 only 33%, so the description must compensate, and it largely does: it specifies that coordinates are a global WGS84 point that must already be known, that a country is supplied, and it explains site_ref chaining in detail (pass unchanged to reuse canonical site, boundary confidence, LPA, evidence links, project context). It does not mention the lat/lng bounds or the country_code lowercase pattern, which remain schema-only.

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 concrete verb and resource: check which registered context/place routes and official research references exist for a given WGS84 point and country. It also distinguishes itself from adjacent capabilities ("no geocoding, dataset retrieval or source health probe"). The phrasing "context/place routes" and "coverage register" is jargon-heavy, so the purpose is clear in outline but not crisp.

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 gives a clear timing cue ("before choosing a task") and explicit exclusions that route the agent away from geocoding, dataset retrieval, and source-health probing, which belong to siblings like boundary_doctor or get_official_source_adapters. It stops short of naming those alternatives directly, so the agent must still infer which sibling to use instead.

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