rf-los-mcp

Overview Schema Source Related Servers Discussions Admin

Rf Los Check

rf_los_check

Check RF line of sight between an observer and target over FABDEM terrain, with optional Fresnel-zone clearance at a given frequency.

Instructions

Check RF line of sight between observer A and target B over FABDEM terrain.

A is the observer (default 1.5 m above ground level); B is the target, e.g. a repeater (default 25.0 m AGL). Coordinates are decimal degrees, heights are metres. a_height_ref/b_height_ref are "agl" (above ground level, the default) or "amsl" (above mean sea level).

There is NO default frequency. Without frequency_mhz the check is geometric only (mode="geometric", no Fresnel zone) and the result says so. With frequency_mhz the 0.6 x first Fresnel zone must be clear for a "clear" verdict (mode="rf"); partial intrusion is "marginal". Take repeater lat/lon and output frequency (MHz) from the repeaterbook tools.

k_factor is the effective earth radius factor (default 4/3, standard atmosphere). snap_radius_m (default 1000 m, max 10000, 0 disables) snaps the TARGET B (not the observer A) to the highest nearby ground within that radius, since repeater coordinates are often imprecise (valley town vs the hilltop site); the move is reported in target_snap. A and B must be different points at most 300 km apart. Vegetation and buildings are not modelled (bare-earth DEM). The first query in a new area downloads a ~12 MB terrain tile per 1 degree square, which can take about a minute; use dem_prefetch to pre-download. One call downloads at most 16 new tiles.

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": {
      "a_lat": "<a_lat>",
      "a_lon": "<a_lon>",
      "b_lat": "<b_lat>",
      "b_lon": "<b_lon>"
    },
    "name": "rf_los_check"
  }
}

Input Schema

Name	Required	Description	Default
`a_lat`	Yes	Latitude, decimal degrees
`a_lon`	Yes	Longitude, decimal degrees
`b_lat`	Yes	Latitude, decimal degrees
`b_lon`	Yes	Longitude, decimal degrees
`k_factor`	No	Effective earth radius factor
`a_height_m`	No	Height in metres
`b_height_m`	No	Height in metres
`a_height_ref`	No		agl
`b_height_ref`	No		agl
`frequency_mhz`	No	Frequency in MHz (no default; omit for geometric-only check)
`snap_radius_m`	No	Target snap radius in metres

Output Schema

Name	Required	Description	Default
`mode`	Yes
`notes`	Yes
`summary`	Yes
`verdict`	Yes
`k_factor`	Yes
`los_clear`	Yes
`a_ground_m`	Yes
`b_ground_m`	Yes
`attribution`	Yes
`distance_km`	Yes
`target_snap`	No
`frequency_mhz`	Yes
`min_clearance_m`	Yes
`a_antenna_amsl_m`	Yes
`b_antenna_amsl_m`	Yes
`worst_obstruction`	Yes
`bearing_a_to_b_deg`	Yes
`bearing_b_to_a_deg`	Yes
`min_fresnel_clearance_ratio`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so well: it discloses result modes ('geometric' vs 'rf'), the clear/marginal verdict thresholds, the A != B constraint, the 300 km cap, bare-earth limitations (vegetation and buildings not modelled), and the target_snap reporting behavior. It also warns about cost — roughly a minute per ~12 MB tile, max 16 new tiles per call — which is exactly the operational trait an agent needs before invoking.

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 structure is well front-loaded — purpose and A/B roles first, then mode semantics, then parameter meanings, then cost caveats. It is dense rather than padded, though a few parenthetical asides could be tightened and the tile-download paragraph sits at the tail where it is easy to miss.

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 an 11-parameter geospatial tool with an output schema already covering return values, the description supplies everything an agent needs to call it correctly: input sourcing, unit conventions, the frequency-dependent mode switch, snapping semantics, distance limits, and download cost. Nothing material is left for the agent to guess.

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 82%, so the baseline is 3, but the description adds genuine meaning beyond it: it explains the a_height_ref/b_height_ref 'agl' vs 'amsl' distinction, that there is deliberately NO default frequency and what happens without it, that k_factor is the effective earth radius factor for a standard atmosphere, and that snap_radius_m moves the TARGET B (not the observer) to the highest nearby ground because repeater coordinates are often imprecise.

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 first sentence states a specific verb and resource — 'Check RF line of sight between observer A and target B over FABDEM terrain' — and immediately defines the roles of A and B, which is the core distinguishing fact versus the sibling rf_los_route. An agent can tell what this computes without opening the schema.

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 conditional guidance: omit frequency_mhz for geometric-only mode, supply it for the 0.6x Fresnel check, and use dem_prefetch to pre-download tiles. It even names an upstream data source (repeaterbook tools) for the inputs. The gap is that it never explicitly contrasts itself with rf_los_route, so the sibling selection for multi-point profiles 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.

Deploy Server