rf-los-mcp

Overview Schema Source Related Servers Discussions Admin

Terrain Profile

terrain_profile

Generates elevation profiles along paths between two or more points, sampling at a chosen interval and optionally applying Earth curvature for radio line-of-sight analysis.

Instructions

Elevation profile (metres AMSL) along a path through 2 or more points.

Samples every spacing_m metres (default 30) along great-circle segments between the points; every input point is a sample. Returns distance in metres from the start, lat/lon and elevation per sample. With include_curvature=true each sample also has curvature_adjusted_m = elevation + d1d2/(2k*R), the terrain as seen against the straight first-to-last chord, with earth bulge for k_factor (default 4/3). At most 20000 samples; for longer paths increase spacing_m. At most 16 new terrain tiles are downloaded per call.

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": {
      "points": "<points>"
    },
    "name": "terrain_profile"
  }
}

Input Schema

Name	Required	Description
`points`	Yes
`k_factor`	No	Effective earth radius factor
`spacing_m`	No	Sample spacing in metres
`include_curvature`	No

Output Schema

Name	Required	Description	Default
`points`	Yes
`attribution`	Yes
`sample_count`	Yes
`total_distance_m`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses sampling behavior, defaults, the 20000-sample cap, and the 16-new-tile download limit per call — a real side effect most definitions would omit. It leaves gaps on failure modes when DEM tiles are unavailable and on caching behavior after a download.

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?

Purpose is front-loaded in the first sentence, and the following sentences cover sampling, returns, curvature, and limits with no filler. The curvature formula sentence is dense but earns its place because it is the only explanation of a non-obvious parameter.

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?

For a 4-parameter computation tool with an output schema present, the description covers the behavioral essentials: sampling, caps, tile downloads, and curvature math. Error handling and auth/rate-limit context beyond the tile cap are the remaining omissions.

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

Parameters5/5

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

Schema description coverage is only 50%, and the description compensates well: spacing_m's default and sampling role, k_factor's default of 4/3 as an effective earth radius factor, and an explicit curvature_adjusted_m formula using d1*d2/(2*k*R) that the schema never provides. The minimum-points constraint is also explained operationally.

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?

States a specific verb and resource: an elevation profile along a path through 2+ points, in metres AMSL. The multi-point path scope implicitly separates it from a single-point sibling like terrain_elevation, but no sibling is named explicitly, so it stops short of full differentiation.

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

Usage Guidelines3/5

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

The 2+ point requirement and the 'for longer paths increase spacing_m' hint imply when the tool applies, but there is no explicit when-to-use/when-not-to-use guidance or comparison to terrain_elevation, rf_los_route, or dem_prefetch for nearby use cases.

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

Deploy Server