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

With no annotations, the description carries the full burden and does well: it discloses billing ($3/month or $1/24h), both auth mechanisms (api_key param or Authorization: Bearer header), the data source and fallback, and the null-at-sea edge case. It omits error behavior for invalid coordinates and whether each call consumes credit.

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?

Compact and mostly front-loaded, but it opens with pricing rather than the core action, delaying what the tool actually does. No wasted sentences otherwise.

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 the return explanation is a bonus rather than a requirement. Auth, cost, resolution, fallback, and the null-at-sea case are all covered; only error handling and coordinate conventions are missing for a fully self-contained definition.

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 coverage is 0%, so the description must compensate; it does explain api_key (account key or Bearer header), which the schema does not. However, lat/lon get no format, CRS, or coordinate-order guidance beyond 'one point', which matters in a toolset that ships detect_coordinate_order and guess_crs.

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?

States a specific resource (height above mean sea level of one point), names the source dataset (Copernicus GLO-30, GLO-90 fallback), and contrasts itself with a sibling (get_terrain_profile) for the coarser case. An agent can distinguish a single-point lookup from profile/terrain tools without opening the schema.

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?

Explicitly routes the free/coarse use case to get_terrain_profile, and the pricing line implies this is the paid, precise option. It does not address when to prefer get_elevation_profile, the other closely related sibling, leaving one obvious alternative unaddressed.

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