swisstopo_get_egrid

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context about the need for a supported canton, which could cause errors otherwise. It doesn't contradict annotations and provides the key behavioral constraint beyond what annotations state.

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 extremely concise: one main sentence, a use_case block, and a short important note. It's well-structured with tagged sections, front-loads the core purpose, and every sentence earns its place without redundancy.

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 simple lookup tool with strong annotations and an output schema, the description covers the primary use case, an alternative, and an important prerequisite. It misses explicitly stating the coordinate pair requirement, but the schema handles that detail. Overall, it's adequately complete for an agent to invoke correctly.

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?

The tool description does not explain parameter semantics; it only says 'aus Koordinaten' (from coordinates). The schema does describe each parameter, but with schema_description_coverage at 0%, the description provides almost no value beyond the schema. It gives no hints about the need to supply either lat/lon or easting/northing, nor the coordinate systems.

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 uses the specific verb 'ermittelt' (determines) and clearly identifies the resource (EGRID property ID) and the input (coordinates for a specific canton). It also distinguishes itself from siblings by explicitly directing users to swisstopo_oereb_at for restrictions, resolving the EGRID internally.

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 use_case section states when to use the tool ('wenn die ID selbst gebraucht wird') and explicitly points to an alternative for restriction lookups (swisstopo_oereb_at). The important_notes adds a prerequisite (supported canton), giving clear usage guidance.

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