GeoSpark

Terrain horizon

terrain_horizon

Read-onlyIdempotent

The skyline the terrain makes around a point: for each azimuth, the elevation angle of the horizon and how far away the blocking terrain is (Copernicus 30 m DEM, Earth curvature and refraction). Use for solar-panel shading, valley sunlight, or what hills hide. ~10-60 s.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "terrain_horizon"
  }
}

Input Schema

Name	Required	Description
`latitude`	Yes	Latitude in degrees (WGS84)
`step_deg`	No	Azimuth spacing; must divide 360
`longitude`	Yes	Longitude in degrees (WGS84)
`max_distance_m`	No	How far out to look for blocking terrain, in metres
`observer_height_m`	No	Eye or sensor height above ground

Output Schema

Name	Required	Description	Default
`units`	No	Unit of each numeric field
`method`	Yes
`status`	No		ok
`highest`	Yes
`latitude`	Yes
`warnings`	No	Caveats to tell the user
`longitude`	Yes
`provenance`	No	Source, licence, attribution, retrieval time and method
`azimuths_deg`	Yes
`max_distance_m`	Yes
`observer_height_m`	Yes
`ground_elevation_m`	Yes
`horizon_elevation_deg`	Yes	Skyline elevation angle at each azimuth
`obstruction_distance_m`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026
- addedInput schema / properties / max_distance_m / description
```
Added value: +"How far out to look for blocking terrain, in metres"
```
AddedOct 25, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the data source (Copernicus 30 m DEM), that Earth curvature and refraction are modeled, and an expected runtime of ~10-60 s. It does not say whether the DEM excludes buildings or vegetation, which matters for shading use cases.

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?

Three sentences: definition first, intended use second, cost last. Every clause carries information — dataset, physical corrections, use cases, latency — with no filler, and the cost estimate is placed where an agent will see it before committing.

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 an output schema present, return values need no explanation, and all five parameters are fully documented in the schema. Runtime, data source and physics are disclosed, leaving only minor gaps such as surface-cover limitations of the DEM.

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% with per-parameter descriptions, ranges and defaults for all five inputs, so the schema carries the parameter burden. The description only echoes azimuth spacing and look-out distance at a conceptual level without adding format or constraint detail, 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 names a concrete output (per-azimuth horizon elevation angle plus distance to the blocking terrain) produced from a named dataset, so an agent can distinguish this from point-elevation or line-of-sight tools. It stops short of naming a sibling it should be swapped for, so the differentiation is inferred from the output shape rather than stated.

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?

"Use for solar-panel shading, valley sunlight, or what hills hide" gives clear positive usage contexts that implicitly separate it from sun_position and get_elevation. There are no exclusions or prerequisites (e.g., when a single-point elevation query suffices instead), so the guidance is clear but not complete.

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

All GeoSpark tools Inspect

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.