Skip to main content
Glama

Elevation, profile and contour lines

get_elevation
Read-onlyIdempotent

Use this when the user asks how high a place is (altitude, height above sea level), wants an elevation profile or the climb between places (a hike, a ride or a road up a mountain: elevation gain and loss, highest and lowest points, cross-section), or asks about the terrain of an area, anywhere in the world: a DEM, relief or hillshade for QGIS, contour lines (topographic lines) and how steep or flat it is (slope). Place names work directly, for example a town and a summit. Reads the values from Copernicus DEM, a 30 m surface model of the whole world, and returns the numbers, a profile chart, the path or contours on a map and files. mode "point": up to 100 points. mode "path": 2 or more points, sampled into at most 500 samples. mode "area": a bbox, a place or a place with a radius, of any size: returns the DEM clipped to the area as a GeoTIFF (30 m, coarser for very large areas), a hillshade GeoTIFF and a slope GeoTIFF, which open directly in QGIS; for areas up to about 10 x 10 km it also returns contour lines (interval_m between lines; Shapefile, GeoJSON, KML) and slope statistics, so one call answers how steep a site is. Not for routes or travel times. Needs a place, coordinates or an area: to explain what a DEM, a DSM or contour lines are, answer without this tool. Never use the user's current location unless they type it. Give the place as the user names it (place name, address or coordinates): this tool locates it, so find_places is not needed first. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.

Input Schema

NameRequiredDescriptionDefault
areaNoFor area: The area: a bbox, or a place (name, address or coordinates) with an optional radius in metres. The place the user asks about, not the user's own location.
modeNopoint: elevation of each point; path: profile along the points; area: DEM, hillshade and slope GeoTIFFs, plus contour lines and slope statistics for small areas.point
pointsNoFor point and path: points or place names. The place the user asks about, not the user's own location.
samplesNoFor path: number of samples along the path.
interval_mNoFor area: vertical interval between contour lines, in metres.

Output Schema

NameRequiredDescriptionDefault
codeNoError code, on errors only.
hintNoWhat to do next, on errors only.
messageNoError message, on errors only.
sourcesNoData sources and licences of the result.
downloadsNoDownload links; each builds its file when opened.
truncatedNo
totalFoundNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / mode / description
      Previous value: -"point: elevation of each point; path: profile along the points; area: contour lines and slope statistics."New value: +"point: elevation of each point; path: profile along the points; area: DEM, hillshade and slope GeoTIFFs, plus contour lines and slope statistics for small areas."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent, and the description adds substantial context beyond them: data source and resolution, per-mode sampling limits (100 points, 2+ points sampled to ≤500 samples), the ~10x10 km threshold for contour output, and the non-obvious fact that download links build the file on open with nothing saved server-side.

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

Conciseness4/5

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

Front-loaded with the user-facing trigger before the technical detail, which is the right ordering. It is dense and somewhat long, with mild repetition of the return payload (chart/contours vs. the later DEM/hillshade/slope GeoTIFF list), but almost every sentence carries operational information.

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

Completeness5/5

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

For a five-parameter, mode-switching tool with nested area objects and an output schema, the description covers inputs, outputs, limits, data provenance, and the sibling-routing caveats. Nothing an agent needs in order to choose a mode and call correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description goes slightly further by tying each mode to the parameters it activates (points for point/path, area for bbox/place/radius, interval_m for contour spacing) and stating the any-size area behaviour, though most of these constraints are already present in the schema.

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

Purpose5/5

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

States a specific verb+resource set (altitude lookup, elevation profile, terrain DEM/contours) and names the concrete data source (Copernicus DEM, 30 m). It also draws explicit boundaries against siblings: 'find_places is not needed first' and 'Never pass these links to open_gis_file.'

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

Usage Guidelines5/5

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

Opens with an explicit when-to-use trigger list (altitude, climb between places, terrain/contours/slope), followed by when-NOT-to-use ('Not for routes or travel times', don't use it to explain what a DEM is, don't use the user's current location unless typed). Alternatives are named and the conditions that select them are stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources