Skip to main content
Glama

SeekSat

Pass sky chart

get_pass_chart
Read-onlyIdempotent

Render a polar sky chart (PNG) of a satellite's pass over a location: where to look, with the moon, planets and stars in their real positions. Returns JSON (the charted pass as a full pass row, the same as find_passes gives, and a one-line summary) and the image. A geostationary satellite has no passes: the result gives stationary (where to point) instead. By default it charts the next pass; give time (the rise or peak of a pass from find_passes or best_pass) to chart that pass instead. Use the same minElevation as the pass came from. A time more than 30 days from the orbital elements' epoch is refused.

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_pass_chart"
  }
}

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).
modeNo"visual" (default): naked-eye passes, sunlit while the sky is dark; "radio": every line-of-sight pass, day or night.
timeNocharts the pass around this time (a pass's rise or peak from find_passes or best_pass). Default: the next pass from now. 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.
skyTypeNohow dark the observer's sky is, for the visual rating as on seeksat.com: "city" (stars to magnitude 3.5), "suburban" (stars to magnitude 4.5), "rural" (stars to magnitude 5.5), "dark" (stars to magnitude 6.5). Default "suburban".
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".
windowHoursNohow far ahead to look, in hours, up to 240 (10 days). Default 72. Only used to find the next pass when no time is given.
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.6/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, open-world behavior, and the description adds substantive context beyond them: the mixed JSON+image return, the 30-day-from-epoch refusal, and the alternate 'stationary' response for geostationary satellites. An agent knows the outcome shape and the key failure mode before calling.

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?

About five sentences, front-loaded with what gets rendered and returned, then defaults, then the geostationary and epoch caveats. Dense but nearly every clause carries information; the return-value sentence is slightly cluttered by the 'same as find_passes gives' comparison.

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?

There is no output schema, so the description carries the return-shape burden and does so (pass row, summary line, image, or 'stationary'). For a 12-parameter tool with an image artifact and a time-window constraint, nothing an agent needs to call it correctly is missing.

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 the baseline is 3, but the description adds real meaning on top: 'time' must be a rise or peak taken from find_passes or best_pass, and minElevation should match the pass it came from. It does not elaborate on lat/lon, windowHours, or skyType, which is acceptable since the schema already covers them in detail.

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?

States a specific verb and artifact ('Render a polar sky chart (PNG) of a satellite's pass over a location') and lists the content of the chart (moon, planets, stars in real positions). It also names the exact return payload (pass row plus one-line summary plus image), which clearly separates it from find_passes, which only finds passes.

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?

Gives explicit when-guidance: default charts the next pass, and supplying 'time' from find_passes or best_pass charts that pass instead, with the instruction to reuse the same minElevation. It also covers the geostationary edge case. What it lacks is an explicit statement of when to use a different tool (e.g. for radio passes) instead of merely setting mode='radio'.

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