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

Annotations already mark readOnlyHint=true and openWorldHint=true, so the description does not need to repeat basic safety. It adds genuinely non-obvious behavior: fallback to a coarser level when the requested level is missing and the result is recognizable via place_type, distance-0 inclusion in any radius, limit clamping, and the anti-hallucination instruction to use only returned names. Nothing in the description contradicts the 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 dense but highly structured: purpose, boundary, required args, optional args, fallback behavior, instruction source, and anti-hallucination rule each get a clearly labeled section. Although it is longer than many descriptions, every sentence carries operational value; there is no filler or tautology.

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 6-parameter tool with no output schema, the description covers all parameters, defaults, edge cases, sibling-tool routing, and output interpretation (place_type fallback indicator). It also gives an anti-fabrication rule for returned names, which is critical practical guidance. The reference to get_usage_guide fills any remaining serialization detail without bloating the main description.

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, and the description goes beyond it by adding the one-spelling-per-call rule, explaining the nearest-hit behavior when radius_m is omitted, and clarifying that unknown level values behave like 'place'. It largely restates schema semantics for radius_m and limit, but it provides extra operational context that helps an agent invoke the tool correctly.

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 action and resource: names what lies at a coordinate, optionally at a chosen level, including street-level reverse geocoding. The first sentence alone tells an agent not just what the tool returns but that it is the lookup for a GPS start position. It also distinguishes itself from nearby and search_place, making sibling confusion unlikely.

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 gives when-to-use guidance: reverse geocoding a coordinate, street labeling for GPS positions, and the distinction from search_place (name → coordinate), nearby (what lies around), and another resolution tool. It also states required parameters, the mandatory spelling consistency rule, and points to get_usage_guide for further detail.

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