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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond these: it explains the data source (GEBCO WMS), the optional sub_ice_topo variant, public domain availability, and no auth requirement. It also clarifies output semantics through examples, which is helpful for an agent to interpret results.

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 three sentences, front-loaded with the core purpose, and includes only relevant details: sign convention, examples, optional parameter, and data sourcing. No filler or redundancy; every sentence contributes to agent understanding.

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 tool with three parameters, an output schema, and clear annotations, the description is sufficiently complete. It covers the main functionality, optional surface parameter, data provenance, and auth requirements. It does not mention resolution or accuracy limitations, but those are not essential for basic invocation, and the output schema covers return structure. A minor gap is the lack of explicit pointer to the sibling profile tool for multi-point queries.

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 input schema already describes all three parameters (lat, lon, surface) with 100% coverage, including the enum for surface and example coordinates. The description adds interpretative context for the output (sign) and the sub_ice_topo option, but it does not significantly enhance each parameter's meaning beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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 retrieves elevation or seafloor depth at a single lat/lon point from the GEBCO grid, and explicitly notes the sign convention relative to sea level. It names the data source and gives concrete examples (Mariana Trench, Himalayas), which distinguishes it from generic elevation tools and clarifies its specific scope.

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 use for a single point ("at a single latitude/longitude point") and mentions the optional sub_ice_topo parameter, but it does not explicitly contrast this with sibling tools like gebco.elevation.profile or other elevation providers. No when-not-to-use guidance is provided, leaving some inference to the agent.

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