Maps by DeltaBreen

elevation

Read-only

Height above sea level (metres) at points, or an elevation profile along a path: each sample's height and distance along, plus length, ascent, descent, min and max. Oceans answer their depth (negative). Heights come from a global terrain model (about 100 to 150 m per pixel, so summits read a little low; resolution_m says how fine each answer is). Counts one lookup against the workspace's monthly searches per call, however many points, on every plan; past the plan it returns searches_exhausted and nothing is charged. Show the returned attribution with the results.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "elevation"
  }
}

Input Schema

Name	Required	Description
`path`	No	A route or line to profile, each vertex [lng, lat], 2 to 1,024: it is sampled evenly by distance.
`key_id`	No	The map key (uuid from list_keys) to count the lookup against. Default: the workspace's first active secret key, else its first publishable one.
`points`	No	Points to read, each [lng, lat], up to 512. Give points OR path, not both.
`samples`	No	How many samples along the path, 2 to 1,024 (default 100).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With annotations only covering readOnly and openWorld, the description carries substantial extra weight and delivers: data provenance (global terrain model at 100–150 m/pixel), a disclosed accuracy bias (summits read low), a returned resolution_m, the oceans-return-negative-depth rule, quota consumption per call, the searches_exhausted terminal state with no charge, and an attribution obligation. These are exactly the behavioral facts annotations cannot express.

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 capability is front-loaded in the first clause and every subsequent sentence adds a distinct fact. It is dense, though, with long parentheticals (the 100 to 150 m pixel aside, the plan/billing sentence) that pack several ideas into single sentences and slow parsing slightly.

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?

There is no output schema, and the description compensates fully by enumerating the return payload: each sample's height and along-path distance, plus total length, ascent, descent, min and max, and resolution_m. Combined with the accuracy caveat and billing behavior, an agent has everything needed to call this and interpret the result.

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 100%, so the schema already documents path, points, samples and key_id in detail. The description adds only indirect meaning — that points and path are mutually exclusive alternatives and that sample granularity affects the profile — without adding format or constraint detail beyond the schema. Baseline 3 is appropriate.

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 opening clause names the exact resource and unit (height above sea level in metres) plus both modes: per-point readings and a sampled path profile. It is a precise verb+resource statement with no sibling in the tool list that could be confused with it, and the negative-depth rule for oceans prevents the most obvious misinterpretation.

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 clearly frames the two invocation modes (points vs. path) and the schema enforces the mutual exclusion, so an agent knows which mode to pick. It also states the cost model (one lookup per call regardless of point count) and the failure mode (searches_exhausted with no charge), which is real usage context. What is missing is any explicit routing guidance or named alternative tool for related spatial questions.

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

All Maps by DeltaBreen tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?