swiss_geo_get_elevation

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

No annotations are provided, so the description carries the full burden. The description identifies this as a read operation ('Get elevation') and names the official service, giving some credibility context. However, it doesn't disclose behavior around coordinate validity, error handling, or whether it strictly requires Swiss coordinates, which are important behavioral traits for a geo tool.

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 a single, well-structured sentence that front-loads the key information: what it returns (elevation in meters), the input format (WGS84), scope (Switzerland), and source (official swisstopo REFRAME service). Every element earns its place with no filler words.

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 2-parameter tool with no output schema and no annotations, the description is reasonably complete but could benefit from stating the output format more explicitly and any behavioral constraints (e.g., Swiss coordinate bounds). The core purpose, input, and result unit are all covered, but edge case handling is unaddressed.

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 schema already documents both lat and lng parameters with examples. The description adds the coordinate system (WGS84) context, which is valuable and not fully explicit in the schema. However, it doesn't add range validation info or clarifying details beyond what the schema provides, so baseline 3 is appropriate.

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?

Description clearly states the verb ('Get elevation'), the exact resource (elevation/altitude in meters), the coordinate system (WGS84), the geographic scope ('anywhere in Switzerland'), and the official service (swisstopo REFRAME). This is a specific, well-scoped purpose that clearly distinguishes it from sibling geo tools like coordinate conversion or location search.

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 implies usage context (retrieving elevation for a lat/lng point in Switzerland) but provides no explicit when-to-use vs alternatives guidance. It doesn't mention limitations like coordinate validity ranges or what happens outside Switzerland. No exclusions or alternative tool references are provided.

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