Skip to main content
Glama

elevation-mcp-server

by io.github.cyanheads
OverviewDiscussionsAdmin

Server Details

Look up elevation worldwide, profile route ascent/descent, grid areas, check terrain line of sight.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.8% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
cyanheads/elevation-mcp-server
GitHub Stars
1
Server Listing
@cyanheads/elevation-mcp-server

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation4/5

The four tools split cleanly by input geometry and intent: point lookups, bounding-box grids, route profiles, and sightline checks. There is mild conceptual overlap among the three sampling tools (get_points, get_grid, get_profile) since all return elevations, but their distinct input shapes and the cross-references in descriptions make selection clear.

Naming Consistency5/5

All tools share the elevation_ prefix and follow a consistent verb_noun pattern (check_line_of_sight, get_grid, get_points, get_profile). The convention is uniform and predictable throughout.

Tool Count5/5

Four tools is well-scoped for a terrain elevation service; each tool covers a genuinely different access pattern (point, area, route, visibility) and none is redundant. There is no filler or bloat.

Completeness4/5

The surface covers the core elevation domain well: point sampling, grid sampling, route profiling, and line-of-sight/Fresnel checks. Minor gaps exist for advanced terrain analytics (e.g. slope/aspect or viewshed), but the main lifecycle of elevation queries is complete.

Available Tools

4 tools
elevation_check_line_of_sightCheck Terrain Line of SightA
Read-onlyIdempotent
Inspect

Check whether terrain blocks the straight sightline between an observer and a target, each at a height above the ground, accounting for earth curvature and atmospheric refraction. Returns a verdict of clear, blocked, or indeterminate (when samples along the line have no data), the minimum clearance and the terrain point that limits it, and the first obstruction from the observer when blocked. With frequency_mhz, it also reports first Fresnel zone clearance against the 60% free-space bar. Where Mapzen reports sea-floor depth over open water, clearance is measured to the sea surface; USGS 3DEP values below 0 m (bay floor in some bays, or dry land) count as received unless water_surface_m sets a water level. Models terrain only: buildings and vegetation are not modeled beyond what the elevation source itself captures, and a ridge narrower than the reported sample spacing can be missed. To see the terrain between the points, call elevation_get_profile on the same two points.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceNoElevation source: auto (default) uses USGS 3DEP where it has data and Open Topo Data (SRTM, with Mapzen terrain tiles where SRTM has no data) for the rest; usgs_3dep uses 3DEP only; opentopodata uses Open Topo Data only. Case is ignored and spaces or hyphens read as underscores, so USGS-3DEP and open topo data are accepted; 3dep, usgs, and epqs are also aliases for usgs_3dep.auto
targetYesTarget location as {lat, lon} in decimal degrees (WGS84).
samplesNoEvenly spaced terrain samples along the line, endpoints included (3–250, default 100). Spacing is reported; a ridge narrower than it can be missed.
observerYesObserver location as {lat, lon} in decimal degrees (WGS84).
earth_modelNoEarth model: flat ignores curvature; geometric applies curvature without refraction; optical applies standard visible-light refraction (coefficient 0.13, default); radio applies the standard 4/3-earth radio refraction (coefficient 0.25).optical
frequency_mhzNoRadio frequency in MHz (30–300,000; 5800 for 5.8 GHz). When set, the result adds first Fresnel zone clearance against the 60% free-space bar; pair it with earth_model radio.
target_height_mNoTarget height above ground, meters (default 0, the ground itself). Set it for a tower, building top, or second antenna.
water_surface_mNoWater level in meters (-500 to 9,000). When set, each sample's surface, endpoints included, is the higher of its elevation and this level, replacing the default that lifts only Mapzen sea-floor values to 0 m. Requires a vertical reference compatible with the sampled terrain; choosing zero or source opentopodata alone does not establish compatibility. No datum conversion is performed.
observer_height_mNoObserver eye or antenna height above ground, meters (default 1.7, standing eye height).

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance on unconfirmed sightlines, thin clearance margins, a clear line short of 60% first Fresnel zone clearance, lines crossing the USGS 3DEP coverage edge, samples over open water or below water_surface_m, and USGS 3DEP values below 0 m.
targetNoThe target's end of the sightline; fields as on observer.
fresnelNoFirst Fresnel zone clearance; present only when frequency_mhz is set. Zone radius = √(λ·d₁·d₂/D) m, with λ = 299.792458 / frequency_mhz, d₁ and d₂ the distances to each end, and D the line length.
samplesNoSamples along the line, endpoints included.
verdictNoblocked when terrain reaches the sightline at any sample; clear when every sample between the endpoints has data and lies below it; indeterminate when samples without data leave the line unconfirmed.
observerNoThe observer's end of the sightline, in decimal degrees and meters. Ground elevation is as the dataset reports it; surface is the higher of the ground and water_surface_m when set, otherwise the ground, or 0 where a Mapzen value below 0 marks open water; sightline = surface + height. resolution_m is absent for mapzen.
distance_mNoGreat-circle distance from observer to target, meters.
attributionNoSources to credit for the returned values, one line per dataset that answered.
earth_modelNoThe earth model applied.
source_modeNoThe source the call used (auto unless the caller chose one).
datasets_usedNoNumber of values each dataset answered.
limiting_pointNoThe sample between the endpoints with the smallest clearance (first on ties); absent when none of them has data. Units, surface, and resolution_m as on observer, with terrain in place of its ground; bulge is the rise of the curved surface above the straight observer-target chord (0 for flat); clearance = sightline − (surface + bulge), and 0 or below means blocked.
min_clearance_mNoSmallest clearance over samples between the endpoints, meters (negative means terrain above the sightline). Absent when none of them has data.
missing_samplesNoSamples no queried dataset answered.
min_clearance_ftNoSmallest clearance in international feet. Absent with min_clearance_m.
first_obstructionNoThe obstructing sample nearest the observer; present only when the verdict is blocked. Fields as on limiting_point.
sample_interval_mNoDistance between consecutive samples, meters.
samples_with_dataNoSamples with an elevation, endpoints included.
obstructed_samplesNoSamples between the endpoints with clearance 0 or below.
vertical_referenceNoHeight-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.
refraction_coefficientNoRefraction coefficient applied. Absent for the flat model.
effective_earth_radius_mNoEarth radius divided by (1 − refraction coefficient), meters. Absent for the flat model.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, openWorld, so the bar is lower — yet the description adds substantial context beyond them: the verdict values (clear/blocked/indeterminate) and what indeterminate means, the minimum-clearance limiting point, first-obstruction reporting, sea-floor/water-surface handling, and explicit modeling limitations (no buildings/vegetation, narrow ridges missed). It also flags the datum-compatibility caveat for water_surface_m.

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 core purpose is front-loaded in the first sentence, and each subsequent sentence carries distinct information (returns, Fresnel behavior, water handling, limitations, sibling routing). It is longer than the ideal but has little filler; the density is justified by the tool's complexity.

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 9-parameter, nested-object tool with an output schema, the description covers everything an agent needs: purpose, conditional outputs, source/earth-model interactions, water-level edge cases, and known modeling blind spots. Return values being described is a bonus rather than a necessity given the output schema.

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 description coverage is 100%, so 3 is the baseline, but the description adds cross-parameter meaning: the Fresnel-zone 60% bar triggered by frequency_mhz and its pairing with earth_model radio, the earth_model default (optical, coefficient 0.13), and the water_surface_m override semantics. This is genuine synthesis beyond the per-parameter schema text.

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 and resource — checking whether terrain blocks the sightline between an observer and a target at given heights — and adds scope qualifiers (earth curvature, atmospheric refraction). It distinguishes itself from siblings by routing to elevation_get_profile for the intervening terrain, so an agent can separate this from the raw point/profile/grid tools.

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?

Gives explicit usage context: use elevation_get_profile to see terrain between the two points, and pair frequency_mhz with earth_model radio. It also scopes applicability (terrain-only analysis; water-surface handling). It stops short of stating when this tool is the wrong choice versus elevation_get_points for a simple obstruction-free lookup.

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

elevation_get_gridGet Elevation GridA
Read-onlyIdempotent
Inspect

Sample a regular grid of terrain elevations across a bounding box and report the highest and lowest sampled points, the mean elevation, and the relief, plus the full elevation matrix with each cell's dataset. Values are point samples at grid nodes (box edges included), not cell averages, so a summit between nodes is missed; to refine a candidate high or low point, call again with a smaller box around it. Over open water, Mapzen cells are sea-floor depths. Rows times columns may not exceed 250.

ParametersJSON Schema
NameRequiredDescriptionDefault
colsNoGrid columns, west to east, edges included (2–25, default 10). rows × cols must be at most 250.
eastYesEastern edge longitude, decimal degrees.
rowsNoGrid rows, north to south, edges included (2–25, default 10). rows × cols must be at most 250.
westYesWestern edge longitude, decimal degrees. Must be less than east; a box crossing longitude 180 must be split into two calls.
northYesNorthern edge latitude, decimal degrees. Must be greater than south.
southYesSouthern edge latitude, decimal degrees.
sourceNoElevation source: auto (default) uses USGS 3DEP where it has data and Open Topo Data (SRTM, with Mapzen terrain tiles where SRTM has no data) for the rest; usgs_3dep uses 3DEP only; opentopodata uses Open Topo Data only. Case is ignored and spaces or hyphens read as underscores, so USGS-3DEP and open topo data are accepted; 3dep, usgs, and epqs are also aliases for usgs_3dep.auto

Output Schema

ParametersJSON Schema
NameRequiredDescription
colsNoNode columns applied.
eastNoEastern edge longitude, as requested.
rowsNoNode rows applied.
westNoWestern edge longitude, as requested.
errorNoPresent when the call failed. Absent on success.
northNoNorthern edge latitude, as requested.
southNoSouthern edge latitude, as requested.
noticeNoGuidance on nodes without data, boxes spanning the USGS 3DEP coverage edge, Mapzen sea-floor values, and node spacing against the source resolution.
summaryNoStatistics over the nodes with data.
attributionNoSources to credit for the returned values, one line per dataset that answered.
source_modeNoThe source the call used (auto unless the caller chose one).
elevations_mNoElevation matrix indexed [row][col], rows north to south, columns west to east.
cell_datasetsNoProvenance matrix with the same [row][col] indexing as elevations_m.
col_spacing_mNoEast-west distance between node columns at the box's center latitude, meters.
datasets_usedNoNumber of values each dataset answered.
latitudes_degNoLatitude of each row, north to south; row 0 is the north edge.
missing_cellsNoNodes no queried dataset answered.
row_spacing_mNoNorth-south distance between node rows, meters.
longitudes_degNoLongitude of each column, west to east; column 0 is the west edge.
cells_with_dataNoNodes with an elevation.
resolution_m_rangeNoRange of source resolutions over values that report one; absent when none does (all Mapzen).
vertical_referenceNoHeight-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses key behavioral traits: values are point samples at grid nodes (edges included), not cell averages; summits between nodes can be missed; Mapzen cells over open water are sea-floor depths; and the 250-cell cap. These are exactly the subtleties an agent needs and are not in the annotations.

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 purpose, then limitations, then the size cap — each sentence earns its place. It is dense but not padded; slight redundancy between the description's 250 limit and the same constraint already in the schema.

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?

With an output schema present, the description need not explain return values, and it covers the sampling semantics, source behavior, and limits an agent needs to invoke this correctly across a bounding box.

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 description coverage is 100%, so the baseline is 3, but the description adds interpretive meaning: what grid-node sampling implies for rows/cols and that over-water cells return depths rather than elevations. It does not add much beyond the strongly documented schema, so a 4 rather than 5.

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 and resource ('Sample a regular grid of terrain elevations across a bounding box') and enumerates what is reported (high/low, mean, relief, full matrix). This clearly differentiates it from siblings like get_points, get_profile, and check_line_of_sight, which are not grid-based.

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?

Gives actionable guidance — refine a candidate high/low point by calling again with a smaller box — and explains the point-sample limitation that motivates it. It does not explicitly name the sibling tools or state when to prefer them over this one, so it falls short of a 5.

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

elevation_get_pointsGet Point ElevationsA
Read-onlyIdempotent
Inspect

Look up ground elevation at up to 100 coordinates in one call, in meters and feet, with the dataset and resolution behind every point. Accepts up to 1,000 submitted positions; only the first 100 are validated and sampled, with counts and next_offset identifying the unvalidated remainder. Continue with originalPoints.slice(next_offset). Inside USGS 3DEP coverage (the US and its territories, plus much of Canada and Mexico) values come from 3DEP at 1–30 m resolution. Elsewhere they come from Open Topo Data: SRTM at about 30 m on land between 60°N and 56°S, and Mapzen terrain tiles beyond SRTM's coverage and over the ocean, where values below 0 m are sea-floor depths. A point with no data in any queried dataset returns status no_data instead of failing the call.

ParametersJSON Schema
NameRequiredDescriptionDefault
pointsYes1–1,000 submitted positions as {lat, lon} objects in decimal degrees (WGS84), or one point object. Only the first 100 are validated and sampled; an invalid unserved tail is validated when resubmitted. Coordinate aliases latitude, longitude, lng, and long are accepted.
sourceNoElevation source: auto (default) uses USGS 3DEP where it has data and Open Topo Data (SRTM, with Mapzen terrain tiles where SRTM has no data) for the rest; usgs_3dep uses 3DEP only; opentopodata uses Open Topo Data only. Case is ignored and spaces or hyphens read as underscores, so USGS-3DEP and open topo data are accepted; 3dep, usgs, and epqs are also aliases for usgs_3dep.auto

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance on points without data, Mapzen sea-floor values, and results mixing 3DEP with Open Topo Data.
pointsNoOne entry per processed position, in input order, at most 100.
attributionNoSources to credit for the returned values, one line per dataset that answered.
next_offsetNoZero-based index immediately after the processed prefix in this call, or null when exhausted. Continue with originalPoints.slice(next_offset), where originalPoints is the array submitted in this call; use each newly submitted array for its next slice.
source_modeNoThe source the call used (auto unless the caller chose one).
points_with_dataNoNumber of points with status ok.
processed_pointsNoPositions validated and sampled in this call, at most 100.
remaining_pointsNoUnprocessed, unvalidated positions remaining in this input.
requested_pointsNoSubmitted positions, including duplicates and coverage misses.
vertical_referenceNoHeight-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent, yet the description adds substantial behavior beyond them: the hard truncation at 100 sampled points, the next_offset/counts continuation contract, and the fact that a data-less point returns status no_data rather than failing the call. It also discloses dataset-specific fallback rules and that sub-zero values over ocean are sea-floor depths.

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 core purpose and the batching limit are front-loaded in the first sentence, and each subsequent sentence carries distinct information (continuation, coverage, source fallback, no_data). It is dense and runs long, but no sentence is filler.

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 tool with non-obvious coverage rules, source fallbacks, and a truncation contract, the description covers everything the agent needs to call it correctly and interpret results; the output schema carries the return shape, so nothing material is missing.

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 coverage is 100% – both 'points' and the 'source' enum are fully documented in the schema, including aliases and the 1,000/100 validation split. The description largely restates the batching behavior and says nothing about parameter formats beyond what the schema already provides, so the baseline 3 applies.

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 opens with a specific verb+resource: 'Look up ground elevation at up to 100 coordinates in one call', and adds scope (meters/feet, per-point dataset and resolution). This is clear, but it never names or contrasts with the sibling tools (elevation_get_grid, elevation_get_profile, elevation_check_line_of_sight), so the agent must infer the point-sampling distinction on its own.

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?

Gives concrete operational context: up to 1,000 positions may be submitted while only the first 100 are sampled, and it tells the agent to continue via originalPoints.slice(next_offset). It also explains when each source applies (3DEP coverage vs Open Topo Data/SRTM vs Mapzen). It stops short of saying when to prefer this tool over its siblings.

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

elevation_get_profileGet Route Elevation ProfileA
Read-onlyIdempotent
Inspect

Sample terrain elevation at evenly spaced points along a route (a polyline of 2–1,000 vertices) and summarize it. Returns total distance, cumulative ascent and descent, start, end, minimum, and maximum elevation, and the steepest climb and descent grades, plus the per-sample profile with each sample's dataset unless include_samples is false. Ascent and descent are summed between samples, so they depend on the sample spacing reported in the result: denser sampling captures more small climbs, down to the source's resolution. Over open water, Mapzen samples are sea-floor depths. Each USGS 3DEP sample is a separate upstream request, so up to 250 samples take roughly 10–30 seconds.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesRoute vertices in travel order, 2–1,000 {lat, lon} objects in decimal degrees (WGS84). Consecutive duplicate vertices are ignored. Antipodal retained segments require an intermediate waypoint, even with endpoint-only sampling; errors identify zero-based submitted vertex indices.
sourceNoElevation source: auto (default) uses USGS 3DEP where it has data and Open Topo Data (SRTM, with Mapzen terrain tiles where SRTM has no data) for the rest; usgs_3dep uses 3DEP only; opentopodata uses Open Topo Data only. Case is ignored and spaces or hyphens read as underscores, so USGS-3DEP and open topo data are accepted; 3dep, usgs, and epqs are also aliases for usgs_3dep.auto
samplesNoNumber of evenly spaced samples along the route, endpoints included (2–250, default 100). More samples catch more relief and take longer; spacing finer than the source resolution adds no detail. For a large count where only the summary matters, set include_samples to false.
include_samplesNoReturn the per-sample profile (default true). false omits samples and the sample table; the summary, spacing, coverage counts, datasets, notices, and attribution are unchanged, still computed from every sample.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance on samples without data, routes crossing the USGS 3DEP coverage edge, Mapzen sea-floor values, and sample spacing against the source resolution.
samplesNoEvery sample in route order, endpoints included. Absent when include_samples is false.
summaryNoRoute statistics over the samples with data, bridging samples without data.
verticesNoRoute vertices after dropping consecutive duplicates.
attributionNoSources to credit for the returned values, one line per dataset that answered.
source_modeNoThe source the call used (auto unless the caller chose one).
datasets_usedNoNumber of values each dataset answered.
missing_samplesNoSamples no queried dataset answered.
sample_interval_mNoDistance between consecutive samples, meters: route length / (samples − 1).
samples_with_dataNoSamples with an elevation.
resolution_m_rangeNoRange of source resolutions over values that report one; absent when none does (all Mapzen).
vertical_referenceNoHeight-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses non-obvious behavior: ascent/descent depend on sample spacing because they are summed between samples, Mapzen returns sea-floor depths over open water, and each USGS 3DEP sample is a separate upstream request costing roughly 10–30 seconds for up to 250 samples. These are exactly the traits an agent cannot derive from annotations or schema.

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 opening sentence front-loads purpose and return contents, then caveats follow in descending priority. It is dense and runs long, but every sentence carries distinct information (spacing dependency, water depths, per-sample request cost) rather than filler.

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?

With an output schema present, the description needn't enumerate return fields, yet it usefully summarizes them; annotations cover safety, and the description fills the remaining gaps — sampling tradeoffs, data-source semantics, and latency expectations — so an agent has everything needed to call this correctly.

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, but the description adds cross-parameter semantics the schema does not: the dependency of ascent/descent totals on the samples spacing reported in the result, and the tradeoff that denser sampling catches more relief at higher latency. It reinforces rather than duplicates the schema's per-field text.

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 verb and resource — sample terrain elevation at evenly spaced points along a route polyline and summarize it — and immediately scopes it with the 2–1,000 vertex constraint. This is clearly distinguishable from siblings like elevation_get_points (discrete points), elevation_get_grid (area grid), and elevation_check_line_of_sight (visibility).

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 gives clear operating context: use include_samples=false when only the summary matters for a large sample count, and that spacing finer than source resolution adds no detail. However, it never names a sibling or states when to prefer elevation_get_points or elevation_get_grid over this tool, so selection among siblings is left to inference.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedelevation_check_line_of_sight3 fields changed
      • changedInput schema / properties / water_surface_m / description
        Previous value: -"Water level in meters (-500 to 9,000). When set, each sample's surface, endpoints included, is the higher of its elevation and this level, replacing the default that lifts only Mapzen sea-floor values to 0 m. Set it where the line crosses water: 0 where USGS 3DEP reports a bay floor, or a lake or tide level."New value: +"Water level in meters (-500 to 9,000). When set, each sample's surface, endpoints included, is the higher of its elevation and this level, replacing the default that lifts only Mapzen sea-floor values to 0 m. Requires a vertical reference compatible with the sampled terrain; choosing zero or source opentopodata alone does not establish compatibility. No datum conversion is performed."
      • changedOutput schema / anyOf
        Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "verdict",
-      "distance_m",
-      "observer",
-      "target",
-      "obstructed_samples",
-      "earth_model",
-      "sample_interval_m",
-      "samples",
-      "samples_with_data",
-      "missing_samples",
-      "datasets_used",
-      "source_mode",
-      "attribution"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "verdict",
+      "distance_m",
+      "observer",
+      "target",
+      "obstructed_samples",
+      "earth_model",
+      "sample_interval_m",
+      "samples",
+      "samples_with_data",
+      "missing_samples",
+      "datasets_used",
+      "source_mode",
+      "vertical_reference",
+      "attribution"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / vertical_reference
        Added value: +{
+  "description": "Height-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.",
+  "type": "string"
+}
    • Changedelevation_get_grid2 fields changed
      • changedOutput schema / anyOf
        Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "south",
-      "west",
-      "north",
-      "east",
-      "rows",
-      "cols",
-      "latitudes_deg",
-      "longitudes_deg",
-      "row_spacing_m",
-      "col_spacing_m",
-      "elevations_m",
-      "cell_datasets",
-      "summary",
-      "cells_with_data",
-      "missing_cells",
-      "datasets_used",
-      "source_mode",
-      "attribution"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "south",
+      "west",
+      "north",
+      "east",
+      "rows",
+      "cols",
+      "latitudes_deg",
+      "longitudes_deg",
+      "row_spacing_m",
+      "col_spacing_m",
+      "elevations_m",
+      "cell_datasets",
+      "summary",
+      "cells_with_data",
+      "missing_cells",
+      "datasets_used",
+      "source_mode",
+      "vertical_reference",
+      "attribution"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / vertical_reference
        Added value: +{
+  "description": "Height-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.",
+  "type": "string"
+}
    • Changedelevation_get_points13 fields changed
      • changedInput schema / properties / points / description
        Previous value: -"1–100 points as {lat, lon} objects in decimal degrees (WGS84). latitude, longitude, and lng keys are also accepted."New value: +"1–1,000 submitted positions as {lat, lon} objects in decimal degrees (WGS84), or one point object. Only the first 100 are validated and sampled; an invalid unserved tail is validated when resubmitted. Coordinate aliases latitude, longitude, lng, and long are accepted."
      • changedInput schema / properties / points / items / description
        Previous value: -"A point as {lat, lon} in decimal degrees (WGS84)."New value: +"A {lat, lon} point: latitude -90 to 90, longitude -180 to 180 (WGS84). The first 100 positions are validated; the unserved tail is unvalidated. latitude, longitude, lng, and long aliases are accepted."
      • removedInput schema / properties / points / items / properties
        Removed value: -{
-  "lat": {
-    "description": "Latitude in decimal degrees (WGS84), -90 to 90.",
-    "maximum": 90,
-    "minimum": -90,
-    "type": "number"
-  },
-  "lon": {
-    "description": "Longitude in decimal degrees (WGS84), -180 to 180.",
-    "maximum": 180,
-    "minimum": -180,
-    "type": "number"
-  }
-}
      • removedInput schema / properties / points / items / required
        Removed value: -[
-  "lat",
-  "lon"
-]
      • removedInput schema / properties / points / items / type
        Removed value: -"object"
      • changedInput schema / properties / points / maxItems
        Previous value: -100New value: +1000
      • changedOutput schema / anyOf
        Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "points",
-      "points_with_data",
-      "source_mode",
-      "attribution"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "points",
+      "requested_points",
+      "processed_points",
+      "remaining_points",
+      "next_offset",
+      "points_with_data",
+      "source_mode",
+      "vertical_reference",
+      "attribution"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / next_offset
        Added value: +{
+  "anyOf": [
+    {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Zero-based index immediately after the processed prefix in this call, or null when exhausted. Continue with originalPoints.slice(next_offset), where originalPoints is the array submitted in this call; use each newly submitted array for its next slice."
+}
      • changedOutput schema / properties / points / description
        Previous value: -"One entry per input point, in input order."New value: +"One entry per processed position, in input order, at most 100."
      • addedOutput schema / properties / processed_points
        Added value: +{
+  "description": "Positions validated and sampled in this call, at most 100.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / remaining_points
        Added value: +{
+  "description": "Unprocessed, unvalidated positions remaining in this input.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / requested_points
        Added value: +{
+  "description": "Submitted positions, including duplicates and coverage misses.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / vertical_reference
        Added value: +{
+  "description": "Height-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.",
+  "type": "string"
+}
    • Changedelevation_get_profile5 fields changed
      • changedInput schema / properties / path / description
        Previous value: -"Route vertices in travel order, 2–1,000 {lat, lon} objects in decimal degrees (WGS84). Consecutive duplicate vertices are ignored."New value: +"Route vertices in travel order, 2–1,000 {lat, lon} objects in decimal degrees (WGS84). Consecutive duplicate vertices are ignored. Antipodal retained segments require an intermediate waypoint, even with endpoint-only sampling; errors identify zero-based submitted vertex indices."
      • changedOutput schema / anyOf
        Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "summary",
-      "sample_interval_m",
-      "vertices",
-      "samples_with_data",
-      "missing_samples",
-      "datasets_used",
-      "source_mode",
-      "attribution"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "summary",
+      "sample_interval_m",
+      "vertices",
+      "samples_with_data",
+      "missing_samples",
+      "datasets_used",
+      "source_mode",
+      "vertical_reference",
+      "attribution"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `degenerate_path`: After dropping consecutive duplicate vertices, fewer than 2 vertices remain, or the route is under 1 m long. `no_coverage`: No sample along the route returned an elevation. `usgs_unavailable`: USGS 3DEP failed: a server error, rate limit, network error, or timeout that outlasted the retries (retryable), or a client error or unexpected status that retrying cannot fix (not retryable). `opentopodata_unavailable`: Open Topo Data failed: a server error, network error, timeout, or unreadable response that outlasted the retries (retryable), or an unexpected status that retrying cannot fix (not retryable). `opentopodata_rate_limited`: Open Topo Data kept answering HTTP 429 through the retries, or asked for a wait over 8 s. `opentopodata_daily_limit`: Only on the public Open Topo Data instance: this server has sent it 1,000 requests in the trailing 24 hours, so no request was sent. `opentopodata_config_rejected`: The Open Topo Data instance answered 401, 403, or 404, a redirect from a self-hosted instance, a 400 naming a dataset it lacks or a location limit below 100, or a 200 naming a dataset this server did not request. `sampling_deadline_exceeded`: The call's 45 s sampling budget ran out (a retry deadline, or a wait in either provider's request queue), or the USGS 3DEP lookups other calls had queued, plus this call's, would not drain within the calls' budgets, so it sent none and data.retryAfter gives the seconds until the queued lookups drain. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `antipodal_path`: A retained path segment has antipodal endpoints after dropping consecutive duplicates, so its shorter arc is ambiguous. `degenerate_path`: After dropping consecutive duplicate vertices, fewer than 2 vertices remain, or the route is under 1 m long. `no_coverage`: No sample along the route returned an elevation. `usgs_unavailable`: USGS 3DEP failed: a server error, rate limit, network error, or timeout that outlasted the retries (retryable), or a client error or unexpected status that retrying cannot fix (not retryable). `opentopodata_unavailable`: Open Topo Data failed: a server error, network error, timeout, or unreadable response that outlasted the retries (retryable), or an unexpected status that retrying cannot fix (not retryable). `opentopodata_rate_limited`: Open Topo Data kept answering HTTP 429 through the retries, or asked for a wait over 8 s. `opentopodata_daily_limit`: Only on the public Open Topo Data instance: this server has sent it 1,000 requests in the trailing 24 hours, so no request was sent. `opentopodata_config_rejected`: The Open Topo Data instance answered 401, 403, or 404, a redirect from a self-hosted instance, a 400 naming a dataset it lacks or a location limit below 100, or a 200 naming a dataset this server did not request. `sampling_deadline_exceeded`: The call's 45 s sampling budget ran out (a retry deadline, or a wait in either provider's request queue), or the USGS 3DEP lookups other calls had queued, plus this call's, would not drain within the calls' budgets, so it sent none and data.retryAfter gives the seconds until the queued lookups drain. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "degenerate_path",
-  "no_coverage",
-  "usgs_unavailable",
-  "opentopodata_unavailable",
-  "opentopodata_rate_limited",
-  "opentopodata_daily_limit",
-  "opentopodata_config_rejected",
-  "sampling_deadline_exceeded"
-]New value: +[
+  "antipodal_path",
+  "degenerate_path",
+  "no_coverage",
+  "usgs_unavailable",
+  "opentopodata_unavailable",
+  "opentopodata_rate_limited",
+  "opentopodata_daily_limit",
+  "opentopodata_config_rejected",
+  "sampling_deadline_exceeded"
+]
      • addedOutput schema / properties / vertical_reference
        Added value: +{
+  "description": "Height-reference context per answering dataset, including unverified references and whether heights share a datum. No vertical datum conversion is performed.",
+  "type": "string"
+}
  2. 4 tool updates
    • First observedelevation_check_line_of_sight
    • First observedelevation_get_grid
    • First observedelevation_get_points
    • First observedelevation_get_profile

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources