Skip to main content
Glama
rf-los-mcp

rf-los-mcp

by aaronjbrown

Rf Los Route

rf_los_route

Assess RF line-of-sight coverage from a waypoint, GPX, or GeoJSON route to target repeaters, with clear/marginal segments, coverage gaps, and verdicts at named stops.

Instructions

Assess RF coverage of target repeaters along a route (e.g. a drive or hike).

Provide the route as EXACTLY ONE of waypoints (list of lat/lon, in order), gpx_path (path to a .gpx file of at most 10 MB readable by this server, ~ expanded; track points, else route points, else waypoints) or geojson_path (path to a .geojson/.json file of at most 10 MB, e.g. an OpenStreetMap export; prefer this over copying GeoJSON coordinates into waypoints, which risks swapping GeoJSON's [lon, lat] order). The file must be valid RFC 7946 GeoJSON (checked against the GeoJSON JSON Schema; other JSON is rejected). GeoJSON LineString/MultiLineString pieces are joined end to end (branching or disconnected pieces are an error); Point features with a name property become named waypoints placed on the line (within 500 m); with no lines, the Points are the route. The route must have non-zero length. Each target has lat, lon, optional name, height_m (default 25.0 m AGL), height_ref ("agl" or "amsl"), and optional per-target frequency_mhz / snap_radius_m which override the call-level values.

Waypoints / GPX points are route GEOMETRY: the route is resampled every sample_spacing_m metres (default 200) along its length, so dense GPS tracks are fine. Per-waypoint verdicts are reported ONLY for NAMED waypoints plus the first ("Start") and last ("End") point: give a name to each stop you want a result for (summit, hut, camp). GPX track points are unnamed geometry; GPX route points and waypoints keep their names. Line of sight is evaluated at the samples, an approximation that can miss narrow ridges between them. At most 10000 line-of-sight checks (samples x targets) per call; for long routes or many targets increase sample_spacing_m.

observer_height_m is the antenna height AGL along the route (default 1.5 m). Route positions are in km. Targets farther than max_range_km (default 100, max 300) from a point are reported out_of_range.

There is NO default frequency: without frequency_mhz the result is geometric only (no Fresnel zone) and says so. Take repeater lat/lon and output frequency (MHz) from the repeaterbook tools. Snapping (snap_radius_m, default 1000 m, 0 disables) moves the TARGETS to higher nearby ground, never the observer waypoints.

For an out-and-back route pass the OUTBOUND LEG ONLY: the return leg repeats the same coverage. Output has per-target coverage segments with percent clear/marginal, verdicts at Start/End and named waypoints, and coverage gaps. Vegetation is not modelled. A first query in a new area downloads ~12 MB per 1 degree terrain tile (about a minute each; at most 16 new tiles per call); use dem_prefetch. At most 50 targets per call, and at most 5,000,000 terrain samples in total (target snapping included).

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": {
      "targets": "<targets>"
    },
    "name": "rf_los_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
targetsYes
gpx_pathNo
k_factorNoEffective earth radius factor
waypointsNo
geojson_pathNo
max_range_kmNo
frequency_mhzNoFrequency in MHz (no default; omit for geometric-only check)
snap_radius_mNoTarget snap radius in metres
sample_spacing_mNoSample spacing in metres
observer_height_mNoHeight in metres

Output Schema

NameRequiredDescriptionDefault
gapsYes
notesYes
summaryYes
targetsYes
route_kmYes
waypointsYes
attributionYes
sample_countYes
waypoint_countYes
skipped_targetsYes
sample_spacing_mYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/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 so: hard limits (50 targets, 10000 LOS checks, 5,000,000 terrain samples, 16 new tiles, 10 MB files), cost side effects (~12 MB per 1-degree tile, ~a minute each, use dem_prefetch), and accuracy caveats (sampling can miss narrow ridges; vegetation not modelled). It also discloses snapping direction — targets move to higher ground, observer waypoints never do — which is a non-obvious behavioral trait.

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 first sentence front-loads purpose and input selection follows logically, with every paragraph carrying real information, so the length is broadly justified for a 10-parameter tool. However it is one dense block with nested parentheticals and some convoluted sentences (the LineString joining / Point naming rules), which could be split into clearer structured sections.

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?

Given an output schema exists, the description need not specify return values, yet it still previews them (per-target coverage segments, percent clear/marginal, Start/End and named-waypoint verdicts, gaps). It covers everything an agent needs to call correctly: input exclusivity, naming requirements for per-waypoint verdicts, defaults, and resource limits.

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?

At 50% schema coverage the description compensates well: it explains route geometry is resampled every sample_spacing_m, that observer_height_m is AGL along the route, that max_range_km beyond-range targets are flagged out_of_range, that snap_radius_m defaults to 1000 m and 0 disables it, and that per-target frequency_mhz/snap_radius_m override call-level values. It also documents target sub-fields including height_m default 25 m AGL and height_ref semantics, going beyond the bare schema types.

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?

"Assess RF coverage of target repeaters along a route" gives a specific verb (assess coverage), resource (repeaters), and scope (along a route), immediately distinguishing it from the point-check sibling rf_los_check and from terrain_profile/elevation tools. The parenthetical "e.g. a drive or hike" anchors the use case concretely.

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

Usage Guidelines5/5

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

It states the exclusive-or rule across waypoints/gpx_path/geojson_path, recommends geojson_path over manual coordinate copying and explains why (lon/lat swap risk), and tells the caller to take frequency from the repeaterbook tools or omit it for a geometric-only result. It also gives exclusions/edge guidance: pass the outbound leg only for out-and-back routes, and raise sample_spacing_m for long routes or many targets.

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