Skip to main content
Glama

Check terrain

check_terrain
Read-only

Check ground elevation along a route or around a point to see if rising or falling terrain affects the 120 m drone limit, with warnings for your planned flight height.

Instructions

Ground elevation along a route or around a point, against the 120 m rule: the 120 m limit is measured from the surface below the aircraft, so rising ground eats into clearance and falling ground can put a fixed-height flight above the limit. Give waypoints (2 to 50 places or [lon, lat] pairs) for a profile, or a place / lat and lon for the ground within radius_m. Reports the highest and lowest ground relative to the take-off point and warnings for the planned flight height. Elevations from Copernicus GLO-90 via Open-Meteo, about 90 m resolution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude in decimal degrees (WGS84).
lonNoLongitude in decimal degrees (WGS84), negative west of Greenwich.
placeNoPlace name, postcode or landmark in the UK, e.g. "Tyndale Monument", "BS1 6QF", "Durdle Door". Use lat/lon instead if you already have coordinates.
formatNotext for a readable report (default), json for structured output, brief for two or three spoken-friendly sentences (use in voice conversations).text
step_mNoRoute mode: sample spacing along the route.
radius_mNoPoint mode: radius of ground to sample.
waypointsNoRoute as place names or [lon, lat] pairs.
flight_height_mNoPlanned height above the take-off point.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context: data source (Copernicus GLO-90 via Open-Meteo), resolution (~90 m), and what is reported (highest/lowest ground, warnings). This goes beyond the annotations without contradiction.

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?

The description is dense but each sentence adds value: purpose, modes, output, and data source. It is front-loaded with the main rule and mode explanation, and avoids unnecessary filler.

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?

Without an output schema, the description adequately describes the return content (highest/lowest ground, warnings) and the context of the rule. It does not cover error handling or edge cases, but for a read-only terrain tool, it is reasonably complete.

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% with per-parameter descriptions. The description enhances this by explaining the route vs. point distinction and how parameters like waypoints and radius_m are used. It also clarifies lat/lon vs. place usage, adding semantic value beyond 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?

The description states a specific purpose: checking ground elevation against the 120 m rule, with two clear modes (route and point). It distinguishes itself from sibling tools like check_route or check_location by focusing on terrain elevation relative to flight height.

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

Usage Guidelines4/5

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

It explicitly describes the two input modes (waypoints for profile, place/lat/lon for radius) and explains the context of the 120 m rule. It does not name alternative tools or exclusion criteria, but the usage context is clear and actionable.

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