Skip to main content
Glama

SeekSat

Satellite position

get_position
Read-onlyIdempotent

Where a satellite is now, or at a given time: the point on Earth straight below it (latDeg, lonDeg, not where it is in your sky), its altitude, and whether it is sunlit, with url (its page on seeksat.com). A location is optional: it only sets the time zone for local times and for reading a time with no offset (UTC without one). 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_position"
  }
}

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).
timeNowhen. Default: 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.
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. Optional here.
passTimeNoold name for time; still accepted.
satelliteYesNORAD catalog number (as a number or a string) or a name, e.g. 25544, "25544" or "iss".

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?

Beyond the readOnly/openWorld/idempotent annotations, it discloses the epoch validity window and the refusal behavior, how local times with no offset are read, and DST edge-case handling ('moved forward, with a note'). It also warns that a place-name location triggers a network lookup, which is real cost information an agent needs given openWorldHint.

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 what is computed and the reference-frame caveat before the optional-location and time-window details. Dense but every clause carries information; the return-field naming is slightly crowded into the opening sentence.

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?

With no output schema, the description does name the return fields (latDeg, lonDeg, altitude, sunlit, url), which is the right compensation. Units for altitude and the exact shape of the response are left unstated, a minor remaining gap for a single-object read tool.

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 a crucial fact the schema does not: the location affects only the time zone used to read local times, not the computed position ('UTC without one'). That prevents a plausible misuse of the lat/lon/location parameters.

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?

Names a specific verb-and-resource pair: the sub-satellite point, altitude, and sunlit state at a time. The parenthetical 'not where it is in your sky' preempts confusion with topocentric tools like get_radio_pass, and it even names the returned fields (latDeg, lonDeg, url).

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?

Clearly says the location is optional and only has a narrow effect, and states the 30-day-from-epoch refusal condition. It doesn't explicitly point to a sibling when the agent actually wants a sky position, which is the most likely wrong turn for an agent who sees the sibling names.

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