Skip to main content
Glama

Elevation and slope

elevation
Read-onlyIdempotent

Returns Copernicus DEM GLO-30 terrain height, slope, and local relief at a point for terrain analysis and site assessment.

Instructions

Copernicus DEM GLO-30 elevation (metres, EGM2008) at a point, plus slope in degrees (Horn 3x3 on a 30 m grid) and local relief in a 150 m window.

Input Schema

NameRequiredDescriptionDefault
latYes
lonYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already establish the read-only, idempotent, open-world safety profile, so the description's job is to add semantics — and it does: units (metres, EGM2008 vertical datum), slope derivation method (Horn 3x3 on a 30 m grid), and the 150 m relief window. It doesn't state what happens near coast/nodata cells, but the methodological detail exceeds what the annotations supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence that front-loads the data source and unit, then appends the derived quantities with their algorithms in parentheses. No filler, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameter descriptions, the description carries the burden of explaining returns, and it does so explicitly (elevation value, slope in degrees, local relief). Only the coordinate convention and edge-case behavior (nodata, ocean) are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description would ideally clarify coordinate conventions. It implies 'at a point' but never states the expected CRS (presumably WGS84 degrees), nor any bounds; however, lon/lat are self-explanatory names and the omission is low-risk.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific product (Copernicus DEM GLO-30) and precisely enumerates the three returned quantities: point elevation, slope, and local relief. That is far more specific than a restatement of the name, though no sibling (e.g. area_summary, which could plausibly overlap) is named to delimit scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives, no prerequisites, and none of the siblings (area_summary, land_cover) are referenced. The agent must infer from the description alone that this is the point-query counterpart to area-level tools.

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