geo_elevation_profile

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds the LV95 coordinate system constraint and the 'profile service' nature, which is useful context beyond annotations. However, it doesn't disclose behaviors like the number of sample points (covered by schema), service limits, or what happens with out-of-Switzerland coordinates.

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?

Single sentence, front-loaded with purpose. It's efficient and wastes no words, though it could arguably include more substance in the same space (e.g., mentioning nb_points or output format). For a one-line description, it's acceptable but minimal.

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?

An output schema exists, so return-value documentation burden is reduced. The description explains the coordinate system (LV95) and the service (geo.admin.ch). However, with 0% schema description coverage and no parameter detail in the description, the agent must rely entirely on field-level hints in the schema for the 4 coordinates plus nb_points. The description is adequate but not rich for a tool with this many semantic parameters.

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%. The description does not compensate by explaining any parameters. The 'params' wrapper object contains 4 required coordinates plus a default nb_points, but the tool description provides zero parameter-level detail beyond what the schema states. The description only mentions 'two LV95 points' generically without explaining easter/northing structure or the nb_points control.

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 'Elevation profile along a line between two LV95 points' with a specific verb (profile) and resource (elevation along a line). It clearly names the geo.admin.ch profile service as the backend. However, it doesn't explicitly distinguish from sibling tools like geo_height, though the purpose is distinct enough that a capable agent would infer the difference.

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 (elevation profile for line segments between two LV95 coordinates) but provides no explicit 'when to use' or 'when not to use' guidance. It doesn't mention alternatives such as geo_height for single-point elevation queries, nor does it state when choosing between these tools would be appropriate.

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