Offline observational astronomy: positions, rise/set, moon phases, eclipses, and seasons.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 7 of 7 tools scored.
Each tool targets a distinct astronomical query: events, ephemeris, moon phase, rise/set, satellite passes, sky position, and visible objects. There is no overlap in purpose, and the descriptions clearly differentiate them.
All tool names follow a consistent 'astronomy_<verb>_<noun>' pattern (e.g., find_events, get_ephemeris, get_moon_phase). The verb is descriptive and the noun indicates the resource, making the naming predictable and intuitive.
With 7 tools, the server covers a broad range of astronomy queries without being overwhelming. Each tool addresses a specific need (events, ephemeris, moon phase, rise/set, satellite passes, sky position, visible objects), and the count is well-scoped for the domain.
The tool set provides comprehensive coverage for common astronomy tasks: finding celestial events, computing positions and ephemerides, predicting satellite passes, and determining visibility. There are no obvious gaps—the server covers both solar system and star positions, as well as time-based queries like moon phases and rise/set.
astronomy_find_eventsastronomy-mcp-server: find sky eventsASearch forward from a start time for the next occurrences of one sky-event class, selected by the event enum: solar_eclipse, lunar_eclipse, equinox, solstice, moon_quarter, opposition, conjunction, max_elongation, or perigee_apogee. Only solar_eclipse takes an observer: pass latitude and longitude to get local circumstances (contact times plus local_visible). Every other class is geocentric and needs no location — a lunar eclipse is the same event everywhere the Moon is up, so it returns contact times and no local_visible. The body-relative events (opposition, conjunction, max_elongation, perigee_apogee) require a body: opposition applies to the superior planets (mars through pluto), conjunction to any planet, max_elongation to mercury and venus, and perigee_apogee to the moon (perigee/apogee), earth, or a planet (perihelion/aphelion). Returns the next count occurrences (default 1). Start defaults to now; pass an IANA timezone for observer-local timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Target body — required for opposition, conjunction, max_elongation, and perigee_apogee; ignored otherwise. "earth" is accepted only for perigee_apogee, which returns its perihelion and aphelion. | |
| count | No | Number of forward occurrences to return. Default 1, max 20. | |
| event | Yes | Which class of event to search for. | |
| start | No | Search start as an ISO 8601 UTC string, e.g. "2024-01-01T00:00:00Z". Defaults to now. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| latitude | No | Observer latitude in decimal degrees — required for solar_eclipse to get local circumstances, ignored by every other event. | |
| timezone | No | IANA timezone for localized output, e.g. "America/Los_Angeles". When omitted, output is UTC-only. | |
| elevation | No | Observer elevation in meters above sea level. Default 0. | |
| longitude | No | Observer longitude in decimal degrees — required for solar_eclipse, ignored by every other event. |
| Name | Required | Description |
|---|---|---|
| events | Yes | The next occurrences of the requested event class, in chronological order. |
| totalCount | Yes | Number of event occurrences returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnly and idempotent annotations by explaining behavioral nuances: solar_eclipse returns local_visible, lunar eclipse returns contact times but no local_visible, body-relative events have body limitations (e.g., earth only for perigee_apogee). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but well front-loaded with the primary purpose. Each sentence adds value, though it could be slightly more scannable with bullet points or shorter sentences. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 1 required, full schema coverage, and output schema present, the description covers all interactions: event-dependent parameter requirements, body restrictions, default behaviors, and output distinctions (contact times vs. local_visible). The agent has enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description adds substantial context: it explains which events require latitude/longitude, which bodies are valid for each event type, defaults for count and start, and timezone behavior. This greatly enriches the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches forward for sky events selected by an enum, with specific verb 'search forward' and resource 'sky-event class'. It differentiates from siblings by focusing on event occurrence search rather than ephemerides, moon phases, rise/set times, or satellite passes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed per-event guidance: solar_eclipse requires observer location, others are geocentric; body-relative events require body with specific planet constraints; start defaults to now; timezone localizes output. While it doesn't explicitly compare to sibling tools, the event-specific constraints are comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astronomy_get_ephemerisastronomy-mcp-server: get small-body ephemerisAFetch a time-series ephemeris for a small body (asteroid or comet) or spacecraft from JPL Horizons — RA/Dec, distance, and apparent magnitude over a span, optionally with observer-relative altitude/azimuth. This covers objects the in-process major-body set cannot. The designation is passed to Horizons verbatim, so it must be in a form Horizons resolves to a single record: a numbered asteroid takes a trailing-semicolon record lookup (e.g. "433;" for Eros, "1;" for Ceres), and a periodic comet takes the DES + closest-apparition form (e.g. "DES=1P;CAP" for Halley) — a bare name like "433 Eros" or "1P/Halley" returns no match or an ambiguous record list and is rejected. Spacecraft take their negative SPK-ID. start and stop are ISO 8601 UTC and stop must be after start; step is a count plus a unit of m, h, d, mo, or y, such as "1d", "1h", or "10m". Supplying observer latitude/longitude yields topocentric coordinates and adds alt/az — supply both or neither. This is a gated, network-backed extension (JPL Horizons is keyless but rate-limited and best-effort); large spans truncate inline at 200 rows, and the truncation notice names the exact start to resume from — one step past the last row returned, because Horizons includes the start instant in its output — so re-calling from there continues the series without repeating a sample. Splitting the range into smaller adjacent spans works too; keep the same step either way so no sample is lost.
| Name | Required | Description | Default |
|---|---|---|---|
| step | No | Step size as a positive count plus a unit of m (minutes), h (hours), d (days), mo (months), or y (years), e.g. "10m", "1h", "1d". Default "1h". | 1h |
| stop | No | Ephemeris stop as an ISO 8601 UTC string, and must be later than start. Defaults to 24 hours after start. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| start | No | Ephemeris start as an ISO 8601 UTC string, e.g. "2024-01-01T00:00:00Z". Defaults to now. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| latitude | No | Observer latitude in decimal degrees — supply together with longitude for topocentric coordinates and alt/az. Supplying one without the other is rejected. | |
| elevation | No | Observer elevation in meters above sea level. Default 0. | |
| longitude | No | Observer longitude in decimal degrees. Supply together with latitude; one without the other is rejected. | |
| designation | Yes | JPL Horizons target, passed verbatim — use a form that resolves to one record. Numbered asteroid: trailing-semicolon record lookup, e.g. "433;" (Eros), "1;" (Ceres). Periodic comet: DES + closest-apparition flag, e.g. "DES=1P;CAP" (Halley), "DES=2P;CAP" (Encke). Spacecraft: negative SPK-ID, e.g. "-48" (Hubble). A bare name like "433 Eros" or "1P/Halley" fails. Look up designations at ssd.jpl.nasa.gov/tools/sbdb_lookup.html. |
| Name | Required | Description |
|---|---|---|
| cap | Yes | The inline row cap that was applied. |
| shown | Yes | Number of ephemeris rows returned. |
| notice | No | Caveats on the returned series — how to retrieve rows omitted by the cap, and whether any rows were dropped. Absent when the whole span came back intact. |
| points | Yes | Time-series of positions, one per step, in chronological order. |
| dropped | No | Rows Horizons returned that carried no usable time, position, or distance and were dropped. Present only when at least one row was dropped, in which case the series has gaps and is shorter than the requested step count. |
| truncated | Yes | True when Horizons returned more rows than the inline cap. |
| designation | Yes | The body designation echoed from the request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: it is network-backed, rate-limited, best-effort, truncates at 200 rows with a resume mechanism, and explains the exact resume strategy. No contradictions with annotations (readOnlyHint, openWorldHint, idempotentHint) are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the purpose and then detailing parameters and behavior. It is dense but not overly verbose; a few sentences could be tightened (e.g., the truncation resume explanation is thorough but slightly long). Nonetheless, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, external service, strict formatting, truncation), the description covers all essential aspects: purpose, designation syntax, parameter constraints, network behavior, and resume strategy. The presence of an output schema further reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning: it explains the designation format with examples (trailing-semicolon, CAP flag, negative SPK-ID), step syntax, ISO 8601 timezone handling, and lat/lon pairing requirement. This goes far beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a time-series ephemeris (RA/Dec, distance, apparent magnitude) for small bodies, comets, and spacecraft using JPL Horizons, with optional alt/az. It explicitly distinguishes this from major-body tools by stating 'This covers objects the in-process major-body set cannot,' making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for small bodies/spacecraft, not major bodies) and detailed formatting rules for the designation parameter. However, it does not name specific sibling tools as alternatives, leaving the 'major-body' tool unidentified. It also warns about network dependency and rate limits, which aids in usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astronomy_get_moon_phaseastronomy-mcp-server: get moon phaseAReport the Moon phase for an instant: illuminated fraction, phase name, synodic age in days since the new moon, phase angle, and the next four quarter phases (new, first quarter, full, last quarter) with timestamps. Answers "what is the moon phase tonight" and "when is the next full moon" in one call without iteration. The time defaults to now; pass an IANA timezone to also receive observer-local timestamps. The phase is geocentric — no observer location is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Instant to evaluate as an ISO 8601 UTC string, e.g. "2024-12-15T00:00:00Z". Defaults to now. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| timezone | No | IANA timezone for localized output, e.g. "America/Los_Angeles". When omitted, output is UTC-only. |
| Name | Required | Description |
|---|---|---|
| age_days | Yes | Synodic age in days since the previous new moon. |
| time_utc | Yes | The instant the phase was computed for, in ISO 8601 UTC. |
| phase_name | Yes | Human-readable phase name (New Moon, Waxing Crescent, First Quarter, …, Waning Crescent). |
| time_local | No | The same instant in the observer-local timezone with offset, present only when a timezone was supplied. |
| next_quarters | Yes | The next four lunar quarter phases (new/first/full/last) in chronological order. |
| phase_angle_degrees | Yes | Moon phase angle in degrees: 0 = new, 90 = first quarter, 180 = full, 270 = last quarter. |
| illuminated_fraction | Yes | Fraction of the lunar disc illuminated, 0 to 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: the phase is geocentric, no observer location is needed, and passing timezone yields observer-local timestamps. This adds beyond annotations but could mention potential limitations (e.g., no other bodies affect output). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 5 sentences, front-loaded with the key purpose, and every sentence adds value (purpose, common queries, defaults, timezone effect, geocentric note). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no nested objects, output schema present), the description fully covers behavior, output items, and the two parameters. It addresses typical user intents and explains the geocentric constraint. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces default behavior and local timestamp functionality, but adds only marginal extra meaning beyond the schema's own descriptions (e.g., 'Defaults to now' and 'localized output' are already in schema). It does not provide new semantic insight that significantly aids parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and clearly states the resource ('Moon phase') and the exact output (illuminated fraction, phase name, etc.). It differentiates from siblings by being the only tool dedicated to lunar phase, and it explicitly answers common queries like 'what is the moon phase tonight'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it defaults to now, can be called without iteration for both current phase and next quarters, and explains the role of the optional timezone. However, it does not explicitly state when NOT to use this tool (e.g., for other celestial bodies or for observer-dependent data), which would strengthen guidance against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astronomy_get_rise_setastronomy-mcp-server: get rise/set timesACompute rise, set, and culmination (transit) times for a body at an observer location, plus the maximum altitude at culmination. For the Sun, also returns the three twilight pairs (civil −6°, nautical −12°, astronomical −18°) so a single call answers "when does the sun set and when is it truly dark." Searches forward from start (default today) and returns the next count cycles (default 1). When the body is already above the horizon at start, the first cycle is the interval in progress: its set is the imminent one and its rise is null, since that rise precedes the search — so a set is never reported earlier than the rise beside it. Circumpolar or never-rises situations are reported as null rise/set fields with an explanatory note rather than an error — the fact is the answer. Default elevation is 0 m; pass an IANA timezone for observer-local times. This server does not geocode — resolve coordinates upstream first.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The body to compute rise/set for. Twilight is included only when this is "sun". | |
| count | No | Number of forward rise/set cycles to return. Default 1, max 31. | |
| start | No | Search start as an ISO 8601 UTC string, e.g. "2024-06-21T00:00:00Z". Defaults to now. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| latitude | Yes | Observer latitude in decimal degrees, north positive. | |
| timezone | No | IANA timezone for localized output, e.g. "America/Los_Angeles". When omitted, output is UTC-only. | |
| elevation | No | Observer elevation in meters above sea level. Default 0. | |
| longitude | Yes | Observer longitude in decimal degrees, east positive. |
| Name | Required | Description |
|---|---|---|
| body | Yes | The body these rise/set cycles are for, echoed from the request. |
| events | Yes | One entry per rise/set/transit cycle, searching forward from the start time. |
| totalCount | Yes | Number of rise/set cycles returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description goes far beyond by detailing how the tool behaves when the body is already above horizon (first cycle's rise is null), how circumpolar/never-rises cases are handled (null fields with notes vs. errors), and that default elevation is 0 m and timezone is optional. This gives the agent a precise mental model of what to expect in non-standard situations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized (∼180 words) and front-loaded with the core purpose. Every sentence earns its place: twilight exception, search direction and count behavior, edge-case handling, defaults, and a limitation (no geocoding). It is well-structured, moving from general to specific without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, edge cases, output schema exists), the description covers all essential aspects: purpose, search logic, special sun behavior, handling of unusual astronomical situations, defaults, and a notable limitation. With an output schema present, return values need not be detailed; the description sufficiently equips an agent to invoke the tool correctly across diverse scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a clear schema description. The tool description mostly echoes those meanings (e.g., 'Searches forward from `start`', 'returns the next `count` cycles') but adds only one nuance: how the first cycle behaves when the body is above horizon (affects semantics of `count` and `start`). This is useful but sparse; the description does not compensate beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Compute rise, set, and culmination (transit) times for a body at an observer location'—a clear verb+resource. It adds unique value like twilight for the Sun and gracefully handles edge cases (circumpolar, already-above), differentiating it from siblings like astronomy_get_sky_position (which gives positions at a time) or astronomy_list_visible (which lists visible bodies). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual cues: it specifies the search direction (forward from `start`), clarifies twilight inclusion is only for the Sun, and tells the agent to resolve coordinates upstream ('This server does not geocode'). However, it does not explicitly name alternative tools for when rise/set times are not needed (e.g., ephemeris or moon phase), so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astronomy_get_satellite_passesastronomy-mcp-server: get satellite passesAPredict visible passes of a satellite (e.g. the ISS, NORAD 25544) over an observer in the next days. Identify the satellite by exactly one of norad_id or name — supplying both, or neither, is rejected. name is matched as a case-insensitive substring of CelesTrak's catalog names, so it resolves only when it picks out a single object: a broader query comes back with the matching objects and their catalog numbers to choose from, and the result echoes the query that resolved it as resolved_from_name. Fetches the object's current GP element set from CelesTrak, propagates it with SGP4 in-process, and returns each pass's rise, peak, and set times with azimuths and the peak elevation. Only passes that are naked-eye-plausible are returned — the satellite must be sunlit at peak while the observer's sky is dark. Every returned pass rises within the requested window: a pass already underway at start is omitted rather than reported with start as its rise, so back up start to see it. A start further than about a month from the element set's epoch is rejected as out of range on that distance alone, and an element set that will not propagate to a window inside that horizon is rejected as a reentry — so an empty passes means only that nothing was visible. CelesTrak publishes only current element sets, so in practice start must be within about a month of today. NORAD catalog numbers and catalog names are found at celestrak.org or heavens-above.com. This is a gated, network-backed extension (CelesTrak is keyless but rate-limited; element sets are cached briefly). Default elevation 0 m; pass an IANA timezone for observer-local pass times.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days ahead to search for passes. Default 7, max 10. | |
| name | No | Satellite name to resolve against CelesTrak, e.g. "ISS (ZARYA)". Matched as a case-insensitive substring of the catalog name, so give the fullest name you have — a short one matches many objects and is rejected as ambiguous. Mutually exclusive with `norad_id` — supply exactly one. | |
| start | No | Search start as an ISO 8601 UTC string, within about a month of the current element set's epoch — for a tracked object that epoch is hours old, so in practice within about a month of today. A start further out is rejected rather than answered from elements that no longer describe the orbit. Defaults to now. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| latitude | Yes | Observer latitude in decimal degrees, north positive. | |
| norad_id | No | NORAD catalog number of the satellite, e.g. 25544 for the ISS. Found at celestrak.org or heavens-above.com. Mutually exclusive with `name` — supply exactly one. | |
| timezone | No | IANA timezone for localized pass times, e.g. "America/Los_Angeles". When omitted, output is UTC-only. | |
| elevation | No | Observer elevation in meters above sea level. Default 0. | |
| longitude | Yes | Observer longitude in decimal degrees, east positive. |
| Name | Required | Description |
|---|---|---|
| passes | Yes | Visible passes (sunlit satellite over a dark-enough sky) in the requested window, chronological. |
| norad_id | Yes | The NORAD catalog number echoed from the request. |
| totalCount | Yes | Number of visible passes found in the window. |
| satellite_name | No | Satellite name as CelesTrak catalogs it (the element set's OBJECT_NAME). |
| resolved_from_name | No | The name query that resolved this object. Present only when the request supplied `name` rather than `norad_id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively explains behaviors beyond the annotations: fetching from CelesTrak, SGP4 propagation, naked-eye plausibility filtering, pass truncation logic, date validity, rate limiting, and caching. This adds significant value given the annotations only indicate read-only, idempotent, and open-world traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence contributes useful information. It is well-organized, starting with the core purpose, then identification rules, then behavioral details, then caveats. A slight trim could improve conciseness, but currently it is efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter usage, constraints, error handling, external dependencies, and output expectations. Given the tool's complexity (8 parameters, network, output schema exists), the description is thorough and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema, such as the name resolution algorithm, ambiguity handling, and the echo of resolved names. It complements the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts visible passes of a satellite over an observer, which is specific and informative. It distinguishes itself from siblings like astronomy_get_rise_set or astronomy_get_ephemeris by focusing on pass prediction with visibility constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on how to identify satellites (by norad_id or name) and explains constraints like start date validity and rejection of ambiguous names. However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astronomy_get_sky_positionastronomy-mcp-server: get sky positionACompute the apparent topocentric position of one solar-system body (sun, moon, mercury through neptune, pluto) or a named bright star for an observer location and instant. Returns equatorial (RA/Dec), refraction-corrected horizontal (altitude/azimuth), and ecliptic coordinates, plus distance, apparent magnitude, angular diameter, phase angle, illuminated fraction, and the constellation it falls in. For a solar-system body it also returns that body card — classification, mean radius, naked-eye visibility — the same values served at astronomy://body/{body}, so a client without resource support does not need a second surface to reach them; a catalog star has no card and the field is absent. Positions are parallax- and aberration-corrected for the given observer; default elevation is 0 m and the default time is now. Supply star (e.g. "Sirius", "Polaris") instead of body to target a catalog star; body is ignored when star is set. Pass an IANA timezone to also receive the observer-local time. This server does not geocode — resolve a place name to latitude/longitude upstream first.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Solar-system body to locate. Omit when targeting a named star via `star`. | |
| star | No | Named bright star to locate (common name or Bayer designation, e.g. "Sirius", "Alpha Centauri"). Takes precedence over `body`. | |
| time | No | Instant of observation as an ISO 8601 UTC string, e.g. "2024-04-08T18:00:00Z". Defaults to now. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| latitude | Yes | Observer latitude in decimal degrees, north positive. | |
| timezone | No | IANA timezone for localized output, e.g. "America/Los_Angeles". When omitted, output is UTC-only. | |
| elevation | No | Observer elevation in meters above sea level. Default 0. | |
| longitude | Yes | Observer longitude in decimal degrees, east positive. |
| Name | Required | Description |
|---|---|---|
| body | Yes | The body or star this position is for, echoed from the request. |
| ecliptic | Yes | Ecliptic-of-date coordinates of the body. |
| time_utc | Yes | The instant of the observation in ISO 8601 UTC. |
| magnitude | Yes | Apparent visual magnitude (lower is brighter). Null for bodies where the engine cannot compute it. |
| equatorial | Yes | Apparent equatorial coordinates, corrected for precession, nutation, parallax, and aberration. |
| horizontal | Yes | Refraction-corrected horizontal coordinates as seen from the observer. |
| time_local | No | The same instant in the observer-local timezone with offset, present only when a timezone was supplied. |
| body_metadata | No | The body card also served at astronomy://body/{body}, copied here so a client without resource support can reach it. Present for the ten solar-system bodies; absent for a catalog star, which has no card. |
| constellation | Yes | The constellation the body currently falls within. |
| phase_angle_degrees | Yes | Sun-body-observer phase angle in degrees. Null when not applicable (e.g. stars). |
| illuminated_fraction | Yes | Fraction of the disc illuminated, 0 to 1. Null when not applicable. |
| angular_diameter_arcsec | Yes | Apparent angular diameter of the disc in arcseconds. Null for point-source convention bodies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds substantial behavioral detail: parallax- and aberration-correction, refraction-corrected horizontal, defaults, the body card inclusion for solar-system bodies, and the precedence of star over body. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence states main purpose, second summarizes output, third explains body card behavior, then positional corrections, defaults, star vs body, timezone, and the no-geocoding caveat. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 7 parameters, output schema, and annotations, the description covers all essential aspects: what it computes, what it returns, how to use body/star, defaults, time behavior, and an important limitation (no geocoding). The output schema exists so return values are already documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds extra semantics: the precedence rule (star overrides body), the default interpretations (time as UTC, elevation 0), and the purpose of timezone. This goes beyond the schema's standalone descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes the apparent topocentric position of a solar-system body or named bright star, specifying the coordinate systems returned (equatorial, horizontal, ecliptic) and additional data (distance, magnitude, etc.). This specific verb+resource+output distinguishes it from sibling tools like astronomy_get_rise_set or astronomy_get_moon_phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using body vs star, default values (time now, elevation 0), and a caveat that the server does not geocode. However, it does not explicitly contrast with sibling tools (e.g., 'use this for a single snapshot position, use astronomy_get_ephemeris for positions over time').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astronomy_list_visibleastronomy-mcp-server: list visible bodiesAThe one-call "what is up right now" answer. For an observer location and instant, iterate every naked-eye solar-system body (and, with include_stars, the bundled bright stars), compute altitude and azimuth, keep those above the horizon, rank them brightest-and-highest first, and attach a plain-language visibility note to each. The whole sky is gated by the Sun's altitude into daylight / civil / nautical / astronomical twilight / dark, returned alongside the list. time is a single evaluation instant, not a window — for "tonight" pass a time after astronomical dusk (use astronomy_get_rise_set on the sun to find it). Default elevation 0 m; use min_altitude to skip objects grazing the horizon. This server does not geocode — resolve coordinates upstream first; pass an IANA timezone for observer-local times on each body.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Evaluation instant as an ISO 8601 UTC string, e.g. "2024-08-12T05:00:00Z". Defaults to now. A single instant, not a window. A value with no zone designator is read as UTC, not the local zone of the server process. | |
| latitude | Yes | Observer latitude in decimal degrees, north positive. | |
| timezone | No | IANA timezone for localized output, e.g. "America/Los_Angeles". When omitted, output is UTC-only. | |
| elevation | No | Observer elevation in meters above sea level. Default 0. | |
| longitude | Yes | Observer longitude in decimal degrees, east positive. | |
| min_altitude | No | Minimum altitude in degrees to include a body. Default 0 (above the horizon); use e.g. 5 to require clearance. | |
| include_stars | No | Include the bundled bright stars alongside planets. Default false. |
| Name | Required | Description |
|---|---|---|
| bodies | Yes | Every body (and optional star) above the minimum-altitude filter, ranked brightest-and-highest first. |
| total_count | Yes | Number of bodies returned above the minimum-altitude filter. |
| sky_condition | Yes | Sky condition derived from the Sun's altitude — the gate for whether faint objects are observable. |
| sun_altitude_degrees | Yes | The Sun's altitude in degrees that produced the sky condition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the agent knows it's safe and deterministic. The description adds context about the sky classification into daylight/civil/nautical/astronomical twilight/dark, explains ranking logic (brightest-and-highest first), clarifies default elevation 0 m and the use of min_altitude to skip grazing objects. This enriches the understanding of what the tool does without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with a high-level summary, dives into specific processing details, provides usage caveats, and ends with a critical constraint (no geocoding). Every sentence adds value, and there is no repetition of information already present in the schema or annotations. The length is appropriate for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (2 required), 100% schema coverage, and an output schema exists, the description is complete. It covers the overall workflow, parameter behavior, the role of the output (sky classification and visibility notes), and critical prerequisites (resolving coordinates upstream). The presence of an output schema means return values don't need explanation, and the description focuses on what the tool does and how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters interact: it ties time to the concept of a single instant vs. window, clarifies that elevation defaults to 0 and min_altitude can filter out grazing objects, and relates include_stars to "the bundled bright stars". It could be improved by explicitly listing the default values mentioned (e.g., elevation=0, min_altitude=0, include_stars=false) but the text is clear enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('iterate', 'compute', 'keep', 'rank', 'attach') and resources ('naked-eye solar-system bodies', 'bundled bright stars') to clearly state what the tool does. It also distinguishes itself from siblings by noting it provides a "one-call 'what is up right now' answer", contrasting with tools like astronomy_get_ephemeris and astronomy_get_rise_set that handle specific calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly addresses when to use this tool ("The one-call 'what is up right now' answer") and when not to, with specific guidance: 'time is a single evaluation instant, not a window', and advises using astronomy_get_rise_set on the sun for finding appropriate times. It also notes the server does not geocode, telling the agent to resolve coordinates upstream first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.