Skip to main content
Glama
Sign In

SeekSat

by com.seeksat
OverviewDiscussionsAdmin

Identify a satellite

identify_satellite
Read-onlyIdempotent

"What was that moving light?" Given where and when a light was seen, lists the satellites that were sunlit, above the horizon and within tolerance degrees of that spot, best match first, from every satellite in the catalog (active satellites plus CelesTrak's visual group). Needs the Sun at least about 3 degrees below the horizon. Say where it was with azimuth (degrees from north) or direction (a compass word such as "NE"), plus elevation (degrees above the horizon); add travel (the compass direction it was moving towards) to rank by direction of travel too. Each candidate has its azimuth, elevation, angular error, direction of travel, magnitude (estimated where none is measured, see magnitudeEstimated), name and a url to its page. Satellites whose orbital elements are more than 14 days from the sighting time are left out and counted (skippedStaleElements).

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": {
      "elevation": "<elevation>"
    },
    "name": "identify_satellite"
  }
}

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).
timeNotime of the sighting. 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.
limitNohow many candidates to return, 1 to 10. Default 5.
travelNothe compass direction it was moving towards, e.g. "NE". Optional, but it sharpens the match.
azimuthNowhere it was, in degrees from north (90 = east), 0 to 360. Give this or direction.
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.
directionNowhere it was, as a compass word: N, NNE, NE, ... or "north-east".
elevationYeshow high it was, in degrees above the horizon (0 to 90, 90 = straight up). Required.
toleranceNohow far off the reported spot a match may be, in degrees, 1 to 45. Default 10.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description still adds real behavior beyond them: catalog scope, the daylight constraint, best-match ranking, and silent exclusion of satellites whose elements are more than 14 days stale with a skippedStaleElements count.

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?

One dense paragraph, but front-loaded with the motivating question and the core behavior; the alternative-input guidance and result shape follow in sensible order. A few clauses (e.g. the 3-degree solar note placement) could be tightened, but nearly every sentence carries information.

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 11-parameter tool with no output schema, the description covers the return fields explicitly (azimuth, elevation, angular error, direction of travel, magnitude with magnitudeEstimated, name, url, skippedStaleElements). Nothing an agent needs to call it correctly or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter, making 3 the baseline. The description adds marginal value by explaining that travel is used to rank by direction of travel and clarifying azimuth vs. compass-word direction, but the same information is largely repeated in the schema fields.

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 resource and outcome: lists sunlit, above-horizon satellites within tolerance of a reported sighting, best match first, drawn from the full catalog plus CelesTrak's visual group. The framing question "What was that moving light?" makes it distinguishable from pass-lookup siblings like find_passes or next_visible_pass without opening a schema.

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 a clear triggering situation (a light was seen at a place and time) and prerequisites (Sun roughly 3 degrees below the horizon), plus what inputs to supply. It does not explicitly name a sibling to use instead for forward-looking queries, so it falls short of full when-not/alternative guidance.

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

All SeekSat toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources