rf-los-mcp

by aaronjbrown

Overview Schema Source Related Servers Discussions Admin

Python

Local

Dem Prefetch

dem_prefetch

Download terrain tiles for a bounding box or center/radius so later elevation and line-of-sight queries work offline.

Instructions

Download terrain tiles for an area so later queries work offline.

Give EITHER a bounding box (south, west, north, east; decimal degrees) OR center_lat, center_lon and radius_km. Each 1 degree tile is about 12 MB and can take about a minute to download. If the area needs more than max_tiles (default 16, at most 100) tiles, nothing is downloaded and an error states the count; raise max_tiles deliberately. Tiles that fail to download are listed in failed (retry later); ocean tiles need no data.

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": "dem_prefetch"
  }
}

Input Schema

Name	Required	Description	Default
`east`	No
`west`	No
`north`	No
`south`	No
`max_tiles`	No
`radius_km`	No
`center_lat`	No
`center_lon`	No

Output Schema

Name	Required	Description	Default
`ocean`	Yes
`failed`	Yes
`requested`	Yes
`downloaded`	Yes
`total_bytes`	Yes
`already_cached`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.2/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 so well: it discloses the ~12 MB and ~1 minute per-tile cost, the default cap of 16 and hard ceiling of 100, the all-or-nothing behavior when the limit is exceeded ('nothing is downloaded and an error states the count'), and that failures land in `failed` while ocean tiles need no data. It stops short of saying whether re-prefetching an already-cached area re-downloads or short-circuits.

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?

The purpose is front-loaded in the first clause, followed by parameter modes, then cost/limits, then failure handling in descending order of decision relevance. Every sentence carries information an agent needs; nothing is padding.

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 eight-parameter, zero-coverage mutation-style tool with no annotations, the description covers selection rules, cost, limits, and failure reporting. Since an output schema exists, it does not need to enumerate return fields, yet it still calls out `failed` where that matters operationally.

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 description coverage is 0%, so the description must compensate, and it largely does: it maps the four bbox parameters with their order and units (south, west, north, east; decimal degrees), names the center/radius alternative with units in the parameter name, and restates max_tiles' default and bounds. It leaves the precedence rules ambiguous if an agent supplies both modes at once.

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 verb and resource ('Download terrain tiles for an area') and adds the payoff ('so later queries work offline'), which is far more specific than the title 'Dem Prefetch'. It does not, however, distinguish itself from the closely related sibling dem_cache_status, so the agent gets no explicit cue about which of the two to reach for first.

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 states the two mutually exclusive parameter modes ('Give EITHER a bounding box ... OR center_lat, center_lon and radius_km') and warns that raising max_tiles should be done 'deliberately'. What's missing is guidance on when prefetching is unnecessary, e.g. consulting dem_cache_status before paying the download cost.

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

Deploy Server