get_elevation_profile

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

With no annotations, the description takes on the behavioral burden and largely succeeds: it discloses the access mechanism (AWS STAC), explicitly states that no credentials are required, and summarizes the JSON return payload including slope statistics and an ASCII map. It falls short of 5 by omitting operational constraints such as bbox size limits or rate restrictions.

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 front-loaded with purpose and organized with Args and Returns sections, making it scan well. The three references at the end add scholarly credibility but do not help an AI agent invoke the tool correctly, which prevents a 5.

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 two-parameter tool with an output schema, the description is mostly complete: it names the data source, explains no-auth access, documents both parameters, and summarizes the return value. It omits potential constraints such as bbox size/area limits and does not explicitly state the default for calculate_slope, though the schema provides that default.

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%, so the description must supply parameter meaning, and it does: bbox is specified as [min_lon, min_lat, max_lon, max_lat] in WGS84, and calculate_slope is explained as computing mean and maximum slope in degrees. This fully compensates for the minimal schema.

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 opens with a specific action ('Extract') and a precise resource ('digital elevation (in meters) and terrain slope' from 'Copernicus DEM GLO-30'). This is clearly distinct from sibling EO tools like calculate_spectral_index or download_copernicus_granule without needing to inspect schemas.

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 provides some useful context: it is zero-config, queries an open AWS STAC, and requires no API keys. However, it does not explicitly state when to choose this tool over alternatives like download_copernicus_granule, nor does it describe exclusions, leaving usage mostly implied.

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