Skip to main content
Glama

SeekSat

Radio pass details

get_radio_pass
Read-onlyIdempotent

Radio details for one pass of a satellite over a location: its known downlink (and uplink) frequencies, the Doppler swing, when to tune to what frequency (at 10 and 30 degrees up and closest approach), and a table (at most 40 evenly spaced rows) of time, azimuth, elevation, range and receive frequency for pointing an antenna and tuning a radio. Uses the next pass above minElevation, or the one peaking nearest time (past or future, within 30 days of the orbital elements' epoch). A satellite that never sets here (geosynchronous) gets the next 24 hours instead. Give frequencyMHz to use a frequency other than the default downlink; the default is the most recently heard downlink when SatNOGS heard one, else the catalog's. Downlinks carry reception from SatNOGS Network observations when known: { state (heard, silent: stations tried and heard nothing, or unknown: no observations, never a sign it is dead), heardLast48h, heardLast7d, heardLast30d, failedLast30d, lastHeard }, listed most recently heard first; receptionSource names the source (CC BY-SA 4.0). Predictions from published elements: the transmitter's own frequency offset is unknown, so the curve's shape is what to compare.

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": {
      "satellite": "<satellite>"
    },
    "name": "get_radio_pass"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoobserver latitude in decimal degrees, north positive (-90 to 90). Give it with lon, or give location instead.
lonNoobserver longitude in decimal degrees, east positive and west negative (-180 to 180).
timeNoa time near the wanted pass's peak (e.g. from find_passes), past or future. Default: the next pass. ISO 8601 with Z or an offset, e.g. "2026-11-14T21:00:00-06:00"; a time with no offset, e.g. "2026-11-14T21:00", is read in the observer's time zone, and the result echoes how it was read (interpretedAs). A local time the clocks skip at a daylight-saving change is moved forward, with a note.
minElevNoold name for minElevation; still accepted.
locationNowhere the observer is, when lat and lon are not given (they win when both are): a Maidenhead grid square (EN52, EN52ve, EN52ve12), coordinates in any common form ("41.88, -87.63", "41.88N 87.63W", "41°52'48"N 87°37'48"W", a Google Maps link or geo: URI), all read locally, or a place name (city, address, landmark) looked up with OpenStreetMap. Prefer lat and lon, or a grid square, when you have them: a place name is a network lookup.
passTimeNoold name for time; still accepted.
satelliteYesNORAD catalog number (as a number or a string) or a name, e.g. 25544, "25544" or "iss". e.g. "so-50" or 27607.
windowHoursNohow far ahead to look, in hours, up to 240 (10 days). Default 48. How far past the start to look for a pass.
frequencyMHzNothe downlink to compute Doppler for, in MHz. Default: the satellite's default known downlink.
minElevationNolowest elevation that counts: a pass must climb above it, and rise and set are when it crosses it, in degrees above the horizon (0 to 90). Default 10.
minElevationDegNoold name for minElevation; still accepted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds substantial context beyond that: default pass selection logic, geosynchronous fallback, frequency default rules (most recently heard downlink else catalog), reception-state semantics, and a caveat about transmitter offsets making curve shape the comparison.

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?

Front-loads the core purpose and remains information-dense. However, the single paragraph is long and packs reception-state field semantics into a run-on clause. Every sentence is relevant for a complex tool, but the structure could be improved with clearer separation.

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?

Covers return contents, default behavior, edge cases, and data-source caveats for an 11-parameter, no-output-schema tool. It does not state what happens when no pass is found within the window or describe error handling, which is a noticeable gap for agent planning.

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 100%, so baseline is 3. The description adds meaning beyond the schema for frequencyMHz (default selection rule) and ties minElevation/time/windowHours to the choice between next pass and nearest-peak pass, including the 30-day and geosynchronous exceptions. That is enough to raise it to 4.

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?

Opens with a specific verb and resource: 'Radio details for one pass of a satellite over a location', then enumerates the exact contents (downlink/uplink frequencies, Doppler swing, tuning schedule, az/el/range table). This is specific enough for an agent to distinguish it from get_pass_chart or find_passes by content alone.

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?

Provides clear context — radio details for pointing an antenna and tuning a radio — which implies when to use it. However, it never explicitly compares this tool to siblings like get_pass_chart or find_passes, and gives no exclusions. Workflow guidance (e.g., getting a pass time from find_passes) appears only in the parameter schema, not the description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources