geo_identify

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is well covered. The description adds useful context about soft-miss vs error semantics, which is genuinely valuable beyond annotations. However, it doesn't disclose behavior around tolerance/limit effects, result count caps, or coordinate system assumptions beyond what annotations and schema provide.

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 compact (three sentences) and front-loaded with the essential question it answers. Every sentence adds value: the purpose, the soft-miss interpretation, and the data source. No wasted words or redundancy with schema/annotations.

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?

The tool has an output schema present, so return format doesn't need explanation. The soft-miss behavior and LV95 framing are well covered, which addresses the main interpretational risks. However, given the nested params structure with 5 fields at 0% schema coverage, the description could note which fields are required (layer, easting, northing) and which are optional (limit, tolerance), though the schema's required list partially covers this.

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 0%, so there are no inline parameter descriptions to compensate. However, the tool has zero parameters at the top level (the actual params live in a nested 'params' object) — the nested IdentifyInput has 5 fields but the description doesn't elaborate on them. The description does provide partial semantic context (LV95 coordinate system) in the main text. With an output schema present and the LV95 framing, a baseline 3 is appropriate, though more per-parameter detail would help.

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 clearly states the tool's purpose: identifies feature attributes at an LV95 point on a given layer via geo.admin.ch MapServer. It uses specific verb+resource and distinguishes from siblings (identify vs search/height/layer discovery). The first line frames the question 'What is at this LV95 point on a given layer?' which is unambiguous.

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 description gives helpful usage nuance: notes that an empty result is a soft miss (nothing at that location), not an error, which guides interpretation. It also names the data source and implicitly distinguishes from geo_search_layers (which finds layer ids) and geo_find. However, it doesn't explicitly state when NOT to use this tool versus the sibling identify-like tools (geo_municipality_at, geo_zoning_at), missing explicit exclusions.

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