Skip to main content
Glama

Tanod Sky

by dev.tanod
OverviewDiscussionsAdmin

skypeek: satellite passes over a location (ISS and others)

satellite_passes
Read-onlyIdempotent

skypeek: the passes of a satellite (default the ISS) over a point in the next 1-3 days: start, highest and end times with azimuth, compass point and elevation, duration, and whether the pass can be seen with the eye (satellite sunlit, sky dark). Input: lat, lon, optional alt_m, norad_id (default 25544, the ISS), days (1-3, default 2), min_elevation (degrees, default 10) and visible_only. SGP4 predictions, not observations, from CelesTrak orbital elements (fetched at most every 2 hours, never per call); only derived pass times and angles are returned, never the element sets, and no endorsement by CelesTrak is implied. Satellites: CelesTrak's 'stations' and 'visual' groups plus NOAA 15 / 18 / 19; another NORAD id is a 422 unknown_satellite (not charged). At most 40 passes. An upstream outage is a 503 upstream_unavailable (not charged; retry later). Typically under 1 s; with a cold orbital-data cache up to a minute or more (a 503 when too slow, not charged: retry). Price: USD 0.002. Free: 5 skypeek calls per IP per UTC day (every skypeek route shares one pool).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesLatitude in degrees (-90 to 90).
lonYesLongitude in degrees (-180 to 180).
daysNoWindow in days (1-3).
alt_mNoObserver altitude in metres.
norad_idNoNORAD catalog number (default 25544, the ISS); CelesTrak 'stations' and 'visual' groups plus NOAA 15 / 18 / 19.
visible_onlyNoOnly passes that can be seen with the eye (satellite sunlit, sky dark).
min_elevationNoLowest elevation counted as a pass, in degrees above the horizon.

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 cover the read-only/idempotent profile, and the description adds substantial extra context beyond them: SGP4 predictions rather than observations, upstream cache refreshed at most every 2 hours (never per call), a 40-pass cap, 422/503 error semantics with 'not charged' notes, latency expectations, pricing, and the shared per-IP free pool.

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?

Dense and front-loaded: the core purpose and inputs come first, then operational caveats. It is long, but nearly every clause (caps, error codes, cache behavior, pricing) carries distinct value; a minor amount of repetition of schema defaults keeps it from a 5.

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?

With no output schema, the description compensates by enumerating the returned fields (start/highest/end times, azimuth, compass point, elevation, duration, naked-eye visibility). Combined with error, cost, cache, and latency disclosure, an agent has everything needed to call and interpret it.

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, but the description adds value beyond the schema by naming the default satellite (25544 ISS), confirming days=1-3/default 2, min_elevation default 10, and explaining that unsupported NORAD ids yield a 422 unknown_satellite. It largely restates schema detail but contributes the validation and supported-set context.

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 resource (computes satellite passes over a lat/lon point) with scope (next 1-3 days, default ISS) and enumerates the returned fields. It is clearly distinguishable from siblings like sun_moon_times or aurora_forecast.

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 clear context: defaults (ISS, 2 days, 10° elevation), which satellites are supported (CelesTrak stations/visual groups plus NOAA 15/18/19), and what an unsupported NORAD id produces. It stops short of naming an explicit alternative tool or when not to use this one.

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

All Tanod Sky 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