SeekSat

Next visible pass

next_visible_pass

Read-onlyIdempotent

Convenience shortcut: the next pass of one satellite from a location (looks windowHours ahead, default 72). Use this only when the user wants "the next pass". Set chart:true to also render that pass's sky chart in this same call. To compare upcoming passes, or find the best one over several days, use find_passes (one satellite) or best_pass (many) instead. When there is no pass, a note says why.

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

Input Schema

Name	Required	Description
`lat`	No	observer latitude in decimal degrees, north positive (-90 to 90). Give it with lon, or give location instead.
`lon`	No	observer longitude in decimal degrees, east positive and west negative (-180 to 180).
`mode`	No	"visual" (default): naked-eye passes, sunlit while the sky is dark; "radio": every line-of-sight pass, day or night.
`chart`	No	true to also render that pass's polar sky chart (PNG) and return it in this same result. Default false.
`minElev`	No	old name for minElevation; still accepted.
`skyType`	No	how 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".
`location`	No	where 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.
`satellite`	Yes	NORAD catalog number (as a number or a string) or a name, e.g. 25544, "25544" or "iss".
`windowHours`	No	how far ahead to look, in hours, up to 240 (10 days). Default 72.
`minElevation`	No	lowest 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.
`minElevationDeg`	No	old name for minElevation; still accepted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds real behavior beyond them: the default 72-hour lookahead, that chart:true renders the sky chart inside the same call, and that when no pass exists a note explains why. It stops short of describing the pass result fields, which keeps it from a 5.

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?

Four tight sentences, front-loaded with the shortcut framing and then the routing rule; nothing is padding. Minor redundancy between the description's windowHours note and the identical schema default, but the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 decision logic and the no-result case but says nothing about what a successful result contains (rise/set times, max elevation, rating). The required satellite parameter and the location-vs-lat/lon choice are left entirely to the schema. Adequate but with a visible gap on return values.

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 description coverage is 100% and every parameter is already documented in-schema (including defaults for windowHours, minElevation, skyType and the location/lat-lon precedence). The description only echoes the windowHours default and the chart flag, adding no syntax or format detail the schema lacks. Baseline 3 applies when the schema carries the parameter burden.

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?

The opening sentence names a specific verb and resource (fetch the next pass of one satellite from a location) and pins the scope with windowHours' default of 72. It explicitly positions itself as a shortcut relative to named siblings find_passes and best_pass, so an agent can tell which tool to reach for without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states both the when ('Use this only when the user wants "the next pass"') and the when-not with the exact alternatives to use instead (find_passes for comparing passes of one satellite, best_pass for the best over several days). This is explicit routing guidance rather than implied usage.

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

All SeekSat tools Inspect

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

Need Help?