CycleCalcs Astronomy

by com.cyclecalcs

Overview Discussions Admin

Server Details

Read-only astronomy calculations: sun, moon, planets, eclipses, twilight and star positions.

Ownership verified

Status: Healthy
Uptime: 99.9% over 54 days
Last Tested: 2026-10-10 18:01
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-30 21:10 across 11 tools

Disambiguation5/5

Each tool targets a distinct astronomical purpose, and the descriptions explicitly cross-reference alternatives (e.g. astro_sky_today vs astro_dark_window vs astro_sun, or astro_moon vs astro_moon_phases vs astro_positions). While some overlap in raw data exists, the intended usage boundaries are unusually clear for an agent.

Naming Consistency4/5

All tools use a consistent astro_ prefix and snake_case, making the set predictable. The only minor deviation is astro_find_place, which is verb_noun, while the rest are mostly noun phrases.

Tool Count5/5

With 11 tools, the server is well-scoped for astronomy calculations. Each tool covers a meaningful, distinct capability without obvious redundancy or bloat.

Completeness4/5

The surface covers a broad range of observing and ephemeris needs: dark windows, eclipses, moon phases, planets, positions, rise/set, and place lookup. Minor gaps remain for niche topics like comets, asteroids, or planetary satellite events, but core workflows are well supported.

Available Tools

11 tools

astro_dark_windowDark moonless observing windowA

Read-onlyIdempotent

Inspect

The genuinely dark, moonless observing window for a night: astronomical night intersected with the Moon being down, ranked across up to 62 nights with a trend. The right tool for "when should I stargaze / photograph the Milky Way / observe deep-sky objects". Location required. For plain twilight times use astro_sun.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	Night to start from. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`nights`	No	How many nights to evaluate and rank. Default 1.
`moon_illumination_max`	No	Treat the Moon as tolerable below this illuminated fraction (0..1) even when up.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	The best genuinely dark observing windows across a range of nights.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds meaningful behavior beyond that: it intersects two conditions, ranks results across up to 62 nights, and includes a trend. It does not mention the DATE_OUT_OF_RANGE/1700-2200 constraint, but that lives in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences, front-loaded with the core behavior, then the use case, then the fallback sibling. Every sentence earns its place with no redundancy.

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 a read-only ranked-list tool with an output schema and full schema coverage, the description supplies everything needed: what it computes, when to use it, the location requirement, and the alternative. Return values are rightly left to the output schema.

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%, so the schema already documents lat/lon/place/tz/date/nights/moon_illumination_max in detail. The description confirms the location requirement and the up-to-62-night ranking, which is only marginal added value over the structured fields. Baseline 3 is appropriate.

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+resource (the dark moonless observing window) with precise scope: astronomical night intersected with the Moon being down. It explicitly distinguishes itself from the sibling astro_sun, so the agent can route correctly without opening schemas.

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?

Names the exact use cases ('when should I stargaze / photograph the Milky Way / observe deep-sky objects') and explicitly redirects to astro_sun for plain twilight times. Both when-to-use and the alternative are spelled out.

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

astro_eclipsesSolar and lunar eclipsesA

Read-onlyIdempotent

Inspect

Solar and lunar eclipses: the next or previous from a date, or all in a range, with type, magnitude, obscuration, Saros series and global geometry. A solar eclipse also carries a computed hybrid flag and, when central, the duration, path width and Sun altitude at greatest eclipse. With a location it adds local circumstances, contact times, and an explicit visible-from-here answer; set visible_only to true to keep only eclipses visible there. include adds the precomputed central path or the circumstances at greatest local eclipse. NOTE: count applies per type, so count=3 with type "both" can return six events.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Last day of an explicit window. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	Anchor date to search from. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`type`	No	Which kind of eclipse to report. Default "both".
`count`	No	How many eclipses PER TYPE to return.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.
`include`	No	Optional extras, added to the default blocks rather than replacing them. "path": the precomputed central path of a solar eclipse as inline GeoJSON (central line, northern and southern limits, and per-minute duration, width, phase and Sun altitude), for the central eclipses that have one; every other eclipse says why it has none. Large: about 65 to 90 KB of JSON per eclipse, returned as both text and structured content, so ask for one eclipse at a time (type "solar", a date just before it, count 1). "greatest": the circumstances at greatest eclipse from the supplied location, inside each solar eclipse's local block (requires a location).
`direction`	No	Search direction from the anchor date. Default "next".
`visible_only`	No	true keeps only eclipses visible from the supplied location (requires a location).

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Solar and lunar eclipses in a date range, optionally filtered to one location.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safe-read profile, and the description adds substantial non-obvious behavior: count applies per type (count=3 with type 'both' can return six events), include='path' returns 65–90 KB per eclipse and should be requested one at a time, place resolution requires preserving a GeoNames credit, and years are limited to 1700–2200. These are exactly the operational caveats an agent needs.

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 the core capability and then layers conditionals (location, include, count caveat) in compact clauses. It is dense but nearly every sentence carries information; only the trailing NOTE could arguably be folded in, so it falls just short of perfect economy.

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 a 13-parameter, read-only, open-world-off tool with a full output schema, the description covers query modes, location behavior, optional extras, the pagination-adjacent count caveat, and the date-range limitation. An agent has everything needed to call it correctly without inspecting the schema.

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 genuinely adds meaning beyond the schema: the per-type semantics of count, the requirement that visible_only/greatest need a location, and the practical advice to request include='path' one eclipse at a time. These go beyond the parameter descriptions themselves.

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 resource (solar and lunar eclipses) plus the three query modes (next/previous from a date, all in a range), and enumerates the data returned (type, magnitude, obscuration, Saros series, geometry). This clearly separates it from siblings like astro_moon_phases or astro_planet_events.

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?

Explains the conditional usage well: supplying a location adds local circumstances and enables visible_only, and include=greatest requires a location. It does not explicitly contrast with siblings such as astro_moon or astro_moon_phases, so it stops short of full when/when-not routing guidance.

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

astro_find_placePlace name to coordinates and timezoneA

Read-onlyIdempotent

Inspect

Resolve a place name to coordinates, region, country, IANA timezone and a stable place_id, or reverse-look-up the nearest places to a lat/lon. Results are GeoNames data (CC BY 4.0); the response carries the required credit in its attribution field, which must be preserved when results are shown. Note the other tools accept a place argument directly, so this is only needed to disambiguate a name, filter by country, or reverse-geocode.

ParametersJSON Schema

Name	Required	Description
`id`	No	A place_id from an earlier result, to fetch that exact place.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`limit`	No	Maximum matches to return. Default 5.
`query`	No	Place name to search for, e.g. "Springfield".
`country`	No	Two-letter ISO country code filter, e.g. "US".

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Coordinates for a place name, or the nearest named places to coordinates.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description's real value-add is disclosing the data provenance (GeoNames, CC BY 4.0) and the obligation to preserve the attribution field in displayed results. That is genuine behavioral context beyond the annotations, though error/pagination behavior is left unstated.

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?

Three dense sentences with the core verb+resource front-loaded, followed by the license obligation and the routing guidance. Every sentence earns its place, though the license sentence could be tightened slightly.

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 an output schema present (return fields need not be explained) and annotations covering safety, the description only needs to cover modes, provenance, and when-to-use — all of which it does. Nothing needed for correct invocation is missing.

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 description coverage is 100%, so the baseline is 3, but the description groups the parameters into meaningful modes (name lookup, country filtering, reverse lat/lon lookup) and reinforces that place_id is a value from an earlier result. That adds mode-selection meaning on top of the per-field docs.

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 description states a precise verb+resource pair and enumerates the outputs (coordinates, region, country, IANA timezone, stable place_id), then covers the reverse-geocoding direction explicitly. It is unmistakably distinguishable from the astronomically-themed sibling tools, which never resolve place names.

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 gives an explicit when-not and three when-to conditions: 'the other tools accept a place argument directly, so this is only needed to disambiguate a name, filter by country, or reverse-geocode.' An agent has a decision rule without needing to inspect siblings.

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

astro_moonMoon state and appearanceA

Read-onlyIdempotent

Inspect

The Moon at an instant or as a daily series: phase name and angle, illuminated fraction, distance, apparent size, libration, bright limb, and the next quarter phases. A location adds rise/set and altitude. For a calendar of new and full moons use astro_moon_phases; for the Moon's exact coordinates use astro_positions.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Last day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`count`	No	Number of daily rows from start (alternative to end).
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	First day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	The Moon's state and appearance, or a sampled series in range mode.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.5/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=false, so safety is covered. The description adds real behavioral context beyond that: it discloses that supplying a location changes the returned fields (rise/set, altitude) and that output includes a daily-series mode. It does not discuss rate limits or failure modes, but the schema already documents the DATE_OUT_OF_RANGE year bounds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, and the capability enumeration is front-loaded ahead of the sibling-routing clauses. Every clause carries information an agent needs.

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 an output schema present, rich annotations, and 100% schema coverage across nine parameters, the description covers the remaining gap: what the tool is for and how it differs from adjacent Moon/position tools. Nothing required to call it correctly 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 description coverage is 100%, so the schema already explains tz, start/end/count, lat/lon, place, and cursor in detail. The description adds nothing about parameter syntax or formats, so the baseline 3 applies.

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 resource (the Moon) with a clear enumeration of what it returns: phase name and angle, illuminated fraction, distance, apparent size, libration, bright limb, and next quarter phases. It also distinguishes itself from siblings astro_moon_phases and astro_positions by name, so an agent can route 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?

Gives explicit routing: 'For a calendar of new and full moons use astro_moon_phases; for the Moon's exact coordinates use astro_positions.' It also states the conditional behavior of supplying a location (adds rise/set and altitude), which tells the agent when extra params are worth sending.

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

astro_moon_phasesLunar phase calendarA

Read-onlyIdempotent

Inspect

Every new moon, quarter and full moon in a window (or the next few from a date): each with its exact instant, distance, apparent size, supermoon classification under both competing definitions, traditional full-moon name, and any eclipse falling on it. Use for "when is the next full moon" and phase calendars. For the Moon's state right now use astro_moon.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Last day of a window. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	Anchor date; the next phases follow it. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`count`	No	How many phase events to return from the anchor date.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	First day of a window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.
`phases`	No	Optional filter of phase kinds. Omit for all four. Example: ["full_moon"] for full moons only.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	New, first quarter, full and last quarter moons in a date range.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.6/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=false, so safety is covered. The description adds real value beyond that by disclosing the richness of the returned records, including that supermoon classification is given under both competing definitions. It does not discuss pagination behavior, though the cursor parameter documents itself.

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-loaded with the operation and the mode choice, then the payload detail, then the sibling routing. The first sentence is dense with output-field enumeration, but every clause conveys something actionable and no sentence is filler.

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?

An output schema exists, so return values need not be spelled out, yet the description still previews them usefully. With all ten parameters documented in the schema and both query modes described, an agent has everything needed to call this correctly.

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 meaning the schema does not: it explains the two alternative calling patterns (a window versus the next few from a date), which is the main semantic decision an agent has to make across the ten 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?

States a specific resource (lunar phase events) and the exact payload each entry carries: instant, distance, apparent size, supermoon classification, traditional name, eclipse. It also names the sibling it is not (astro_moon), so an agent can pick between the calendar tool and the current-state tool without opening either 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?

Gives explicit trigger phrases ("when is the next full moon", phase calendars) and an explicit exclusion routing to astro_moon for the Moon's state right now. The two query modes (start/end window vs anchor date + count) are also stated in prose.

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

astro_planet_boardAll planets at a glanceA

Read-onlyIdempotent

Inspect

All eight planets in one call for a date and optional location: constellation, magnitude, apparent size, elongation from the Sun, morning or evening sky, retrograde state with the next station, rise/set, and a worth-looking-tonight assessment. The right tool for "which planets are visible tonight". For exact coordinates of specific bodies use astro_positions.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`sort`	No	Optional result ordering. Default is by distance from the Sun.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`bodies`	No	Optional subset of planets: mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Which planets are worth looking at right now, and where.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful scope context (a single call returns all eight planets, not a subset) and hints at a computed judgment field, but says nothing about auth, rate limits, or what happens when optional location is omitted. With annotations doing the heavy lifting, this is adequate but not rich.

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-loaded with the core output list, then the use case, then the sibling routing — a sensible priority order with no filler. The middle enumeration of seven returned fields is long but each item is doing real discrimination work, so it is dense rather than wasteful.

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?

An output schema exists, so return-value structure need not be explained, and rich annotations cover the safety profile while a 100%-covered schema covers parameters. The description supplies the remaining piece — sibling routing and the intended question — leaving little an agent would need beyond it. Minor gap: no note on behavior when place cannot be resolved.

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%, so every parameter (tz, lat, lon, date, sort, place, bodies) is already documented with format, ranges and pairing rules. The description only alludes to "a date and optional location" and adds no syntax, default, or constraint detail beyond the schema. 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?

States a specific verb-resource pair (all eight planets in one call) and enumerates exactly what each entry carries: constellation, magnitude, apparent size, elongation, morning/evening sky, retrograde state with next station, rise/set, and a worth-looking-tonight assessment. It also explicitly distinguishes itself from astro_positions, which covers exact coordinates of specific bodies.

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?

Gives an explicit use case ("which planets are visible tonight") and names the alternative tool plus the condition that selects it ("For exact coordinates of specific bodies use astro_positions"). Both the when and the when-not are stated, so no inference is required.

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

astro_planet_eventsPlanet events: apparitions, oppositions, constellation entriesA

Read-onlyIdempotent

Inspect

Dated planet events. For Mercury and Venus, the apparition cycle: inferior and superior conjunctions, greatest eastern and western elongations, peak brightness (a Venus-only event: Mercury's brightness peaks behind the Sun where it cannot be seen), and the rare transits across the Sun; with no dates it also reports where each is in its cycle right now: morning star or evening star, the conjunctions bounding the current apparition, and the live elongation, phase, magnitude and apparent size. For Mars, Jupiter, Saturn, Uranus and Neptune: conjunction with the Sun, western quadrature, opposition and eastern quadrature, the instants the planet's apparent geocentric ecliptic longitude minus the Sun's reaches 0, 270, 180 and 90 deg, each with the planet's constellation, distance, magnitude and elongation. For any of the seven, constellation_entry, returned only when listed in kinds: each crossing of an IAU constellation boundary, with the two constellations and the direction of motion. The right tool for "when does Venus become the morning star", "when is Mars at opposition", or "when does Uranus cross from Taurus into Gemini". For tonight's visibility of all eight planets use astro_planet_board. Mercury and Venus conjunction instants use the classical heliocentric convention, named on each event.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Last day of an explicit window, exclusive. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	Anchor instant; with no start/end the response covers the next full synodic cycle from here. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`kinds`	No	Optional filter of event kinds. Omit for each planet's own family: the seven apparition kinds for mercury and venus, the four Sun-relative kinds for mars to neptune. peak_magnitude only ever fires for venus; the transit kinds are body-specific and genuinely rare. constellation_entry applies to all seven and must be listed.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`bodies`	No	Which planets to report. Default mercury and venus.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Planet events in a date range: the Mercury and Venus apparition events (conjunctions, greatest elongations, Venus's peak brightness, transits across the Sun), the Sun-relative events of Mars to Neptune (conjunction with the Sun, quadratures, opposition) and, when asked for, constellation entries. Stations (retrograde turning points) are not among them: astro_planet_board gives each planet's next station, and the full station list is served by the REST route /v2/retrogrades.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context: constellation_entry fires only when listed in kinds, peak_magnitude only ever occurs for Venus, transits are rare and body-specific, and conjunction instants for Mercury/Venus use the classical heliocentric convention named on each event. It does not mention pagination limits or the response envelope, which keeps it short of 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?

Front-loaded with the core purpose, then organized by body family in one dense paragraph with no filler sentences. It is on the long side and some per-event field detail (constellation, distance, magnitude, elongation) borders on restating likely output, but every clause 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 a zero-required-parameter, 10-param tool with an output schema, the description covers body families, default kinds, the special-case events, time-window semantics, and the sibling alternative. Nothing an agent needs to select or invoke it correctly is missing, and return-value shape is handled by the output schema.

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 description coverage is 100%, so baseline is 3, but the description contributes semantics the schema does not: without dates the tool augments output with the current cycle position (morning/evening star, bounding conjunctions, live elongation/phase/magnitude), the default kinds family per planet, and the fact that constellation_entry is never returned implicitly. That is genuine added meaning over the enum list.

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?

Opens with a specific verb+resource ('Dated planet events') and precisely scopes it by body family: Mercury/Venus apparition cycles, Mars–Neptune Sun-relative events, and constellation crossings. It explicitly names the sibling to use for the adjacent need ('For tonight's visibility of all eight planets use astro_planet_board'), so the agent can separate the two without opening either 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?

Gives concrete triggering questions ('when does Venus become the morning star', 'when is Mars at opposition', 'when does Uranus cross from Taurus into Gemini') and an explicit alternative with its own condition (astro_planet_board for tonight's visibility). It also states the no-dates fallback behavior, so the agent knows what happens if it omits the window.

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

astro_positionsPrecise positions of bodiesA

Read-onlyIdempotent

Inspect

Exact positions for up to 20 bodies at an instant or over a time grid: right ascension and declination in both J2000 and of-date frames, ecliptic longitude and latitude, distance, and, with a location, altitude and azimuth with refraction stated per field. With a location the position is topocentric, but tropical_sign and constellation stay geocentric, and meta.conventions.label_origin says so. Use for "where exactly is X". Do not pass earth. For rise and set TIMES use astro_rise_set; for a visibility overview of all planets use astro_planet_board.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Grid end. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`step`	No	Grid stride, e.g. "1h", "10min", "1d".
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	Grid start (use with end and step). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`bodies`	Yes	Bodies to report. Each entry: One of sun, moon, mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto, or a fixed J2000 target as "radec:RA,DEC" with RA in hours (0-24) and DEC in degrees (-90..90), e.g. "radec:5.6,-5.4" for the Orion Nebula region.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Where each requested body is, at an instant or sampled across a range.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds frame semantics beyond that: with a location the result is topocentric, while tropical_sign and constellation stay geocentric, and the response self-documents via meta.conventions.label_origin. It doesn't mention pagination or the DATE_OUT_OF_RANGE refusal (those live in the schema), so not a full 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?

Front-loaded with the capability and output fields, then routing. Three dense sentences with no filler, though the run-on output enumeration is heavy enough to be slightly harder to scan than it needs to be.

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?

Output schema exists and annotations cover the safety profile, so the description need not explain return values. It nonetheless supplies the frame caveat, the earth restriction, and alternative routing, leaving no decision-relevant gap for a 10-parameter 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 still adds meaning: 'up to 20 bodies' to bodies, and 'at an instant or over a time grid' clarifying how start/end/step/date relate. It also carries the earth exclusion, which is a semantic constraint not encoded in the schema.

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+resource with the exact output fields (RA/Dec in J2000 and of-date, ecliptic lon/lat, distance, altitude/azimuth with refraction). It explicitly names what it is not ('Do not pass earth') and separates itself from astro_rise_set and astro_planet_board.

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?

Gives a concrete trigger ('Use for "where exactly is X"'), an exclusion ('Do not pass earth'), and two named alternatives with the conditions that select them (rise/set TIMES, visibility overview of all planets). Nothing is left to inference.

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

astro_rise_setRise, transit and set timesA

Read-onlyIdempotent

Inspect

Rise, upper transit, set and lower transit for one body at one location, with an explicit status at extreme latitudes (circumpolar, never rises) instead of missing values. Accepts fixed radec targets. For the Sun specifically, astro_sun returns richer twilight structure; for positions between events use astro_positions.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Last day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`body`	Yes	One of sun, moon, mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto, or a fixed J2000 target as "radec:RA,DEC" with RA in hours (0-24) and DEC in degrees (-90..90), e.g. "radec:5.6,-5.4" for the Orion Nebula region.
`date`	No	ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	First day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.
`search_horizon_days`	No	How many days ahead to search when an event does not occur on the requested day (high latitudes).

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Rise, transit and set for one body, for a day or across a range.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description earns credit for a genuine behavioral disclosure beyond structured data: extreme-latitude results return explicit statuses instead of missing values, which tells the agent how to interpret output. It does not cover pagination or any rate/limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the primary operation and the extreme-latitude output nuance, followed by sibling routing. No filler or restated title/name.

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?

An output schema exists, so return values need no explanation, and the description covers scope, edge-case behavior and alternatives. It is slightly incomplete in not signaling that the tool supports a daily-series mode (start/end) or pagination via cursor, which an agent would only discover from the schema.

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%, with each parameter documented in-schema including radec syntax, IANA tz, date formats and the DATE_OUT_OF_RANGE boundary. The description only echoes the radec-target acceptance, adding little beyond the schema, so baseline 3 applies.

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 computation ('rise, upper transit, set and lower transit for one body at one location') and even discloses the edge-case output contract (explicit circumpolar/never-rises status rather than missing values). It also explicitly distinguishes itself from astro_sun and astro_positions, so an agent can route without opening the 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?

Names two alternatives with selecting conditions: astro_sun for richer twilight structure on the Sun, astro_positions for positions between events. That is clear sibling routing, but it omits guidance on the multi-day series mode (start/end) and cursor pagination that the tool also supports, so it is not fully exhaustive.

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

astro_sky_todaySky snapshot for a place and momentA

Read-onlyIdempotent

Inspect

One-call snapshot of the whole sky for a place and moment: moon phase and illumination, which planets are up and worth looking at, the next eclipse, and (with a location) sun times. Reach for this first when the question is broad, like "what is in the sky tonight". For solar-day detail use astro_sun; for choosing an observing night use astro_dark_window; for one planet's exact position use astro_positions.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	A whole-sky snapshot for one place and moment.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds useful behavioral context: the response varies with location ('with a location, sun times'), signalling that omitting location changes the result set. It stops short of noting the attribution/credit obligation that place resolution triggers (that lives in the schema), which keeps it off 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both front-loaded: the scope statement leads, then the sibling-routing clause. No filler, no repetition of schema content, and the broad-vs-narrow decision is placed before the alternatives.

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?

Output schema exists, so return values need not be described here, and all five parameters are documented in the schema. For a zero-required-parameter, read-only snapshot tool, the description gives everything an agent needs to pick it over the nine siblings and call it correctly.

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 tz, lat, lon, date, and place are all fully documented in the input schema, including the UTC/JD date formats and the 1700-2200 range guard. The description only hints that location is optional via '(with a location) sun times', adding nothing the schema does not already carry.

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?

Specific verb+resource ('one-call snapshot of the whole sky for a place and moment') followed by an enumeration of exactly what is returned: moon phase and illumination, visible planets, next eclipse, sun times. It is immediately distinguishable from astro_moon, astro_positions, and astro_sun by the breadth of its output.

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?

Explicit when-to-use ('Reach for this first when the question is broad, like "what is in the sky tonight"') plus three named alternatives with the condition that selects each: astro_sun for solar-day detail, astro_dark_window for picking an observing night, astro_positions for one planet's exact position.

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

astro_sunSunrise, sunset and twilightA

Read-onlyIdempotent

Inspect

The complete solar day for one location: sunrise, sunset, solar noon, day length, civil, nautical and astronomical twilight boundaries, and explicit polar day/night status at high latitudes. Location required. For a series, send start and end (step is whole days, e.g. "1d" or "7d"). For "is it dark enough to observe" prefer astro_dark_window; for a broad snapshot prefer astro_sky_today.

ParametersJSON Schema

Name	Required	Description
`tz`	No	IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
`end`	No	Last day of a range. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`lat`	No	Latitude in decimal degrees, north positive. Send lat and lon together.
`lon`	No	Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
`date`	No	Single day to report, ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`step`	No	Range stride in whole days, e.g. "1d", "7d", "30d". Default "1d".
`place`	No	Place name instead of lat/lon, as "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Resolved server-side; the response then carries a required GeoNames CC BY 4.0 credit in its attribution field, which must be preserved when shown.
`start`	No	First day of a range (use with end instead of date). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". Or jd: followed by a Julian Day on the UT scale, e.g. "jd:2461000.5". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there.
`cursor`	No	Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes	The complete solar day for one location, or one row per day in range mode.
`rights`	No	Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
`warnings`	No	Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
`attribution`	No	The credit line to display verbatim when rights is attribution_required.
`next_cursor`	No	Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
`not_computed`	No	Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists".

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: explicit polar day/night handling at high latitudes and tz-driven local rendering. It stops short of describing pagination/cursor behavior or error modes, which the schema covers instead.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: capability first, then the location/range mechanics, then sibling routing. Every sentence earns its place with zero filler.

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?

An output schema exists, so return-value explanation is not required, yet the description still names the key outputs and the polar edge case. Combined with 100% schema coverage and full annotations, an agent has everything needed to call it correctly.

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%, so the schema already documents lat/lon/tz/date/start/end/step/cursor with format details and the 1700–2200 range. The description only restates 'Location required' and the step format already given in the schema, adding no new parameter meaning.

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/resource (complete solar day for one location) and enumerates exactly what is returned: sunrise, sunset, solar noon, day length, three twilight boundaries, and polar day/night status. This distinguishes it cleanly from siblings like astro_rise_set and astro_dark_window.

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?

Explicitly states the location requirement, gives the range pattern (send start and end, step in whole days with examples), and routes to alternatives with conditions: astro_dark_window for 'is it dark enough to observe' and astro_sky_today for a broad snapshot.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesSep 27, 2026

Changedastro_dark_window1 field changed

changedInput schema / properties / date / description

Previous value: -"Night to start from. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Night to start from. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_eclipses6 fields changed

changedInput schema / properties / date / description

Previous value: -"Anchor date to search from. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Anchor date to search from. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Last day of an explicit window. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Last day of an explicit window. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

addedInput schema / properties / include

Added value: +{
+  "description": "Optional extras, added to the default blocks rather than replacing them. \"path\": the precomputed central path of a solar eclipse as inline GeoJSON (central line, northern and southern limits, and per-minute duration, width, phase and Sun altitude), for the central eclipses that have one; every other eclipse says why it has none. Large: about 65 to 90 KB of JSON per eclipse, returned as both text and structured content, so ask for one eclipse at a time (type \"solar\", a date just before it, count 1). \"greatest\": the circumstances at greatest eclipse from the supplied location, inside each solar eclipse's local block (requires a location).",
+  "items": {
+    "enum": [
+      "path",
+      "greatest"
+    ],
+    "type": "string"
+  },
+  "type": "array",
+  "uniqueItems": true
+}

changedInput schema / properties / start / description

Previous value: -"First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

addedOutput schema / properties / data / properties / central_geometry_note

Added value: +{
+  "description": "Only when solar eclipses are listed: the lunar-radius convention behind hybrid, the greatest_eclipse fields and the path.",
+  "type": "string"
+}

changedOutput schema / properties / data / properties / eclipses / description

Previous value: -"Each eclipse with its peak instant, kind and Saros series."New value: +"Each eclipse with its peak instant, kind and Saros series. Solar rows also carry hybrid (true for an eclipse total along part of its central track and annular along the rest; kind keeps the value at greatest eclipse), hybrid_transitions, and greatest_eclipse_duration_seconds, greatest_eclipse_path_width_km and greatest_eclipse_sun_altitude_deg (null when there is no central line). With include path, each row has a path object: available, and when true an inline GeoJSON FeatureCollection."

Changedastro_moon3 fields changed

changedInput schema / properties / date / description

Previous value: -"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Last day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Last day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / start / description

Previous value: -"First day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_moon_phases3 fields changed

changedInput schema / properties / date / description

Previous value: -"Anchor date; the next phases follow it. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Anchor date; the next phases follow it. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Last day of a window. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Last day of a window. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / start / description

Previous value: -"First day of a window (use with end). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of a window (use with end). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_planet_board1 field changed

changedInput schema / properties / date / description

Previous value: -"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_planet_events9 fields changed

changedInput schema / properties / bodies / description

Previous value: -"Which inferior planets to report. Default both."New value: +"Which planets to report. Default mercury and venus."

changedInput schema / properties / bodies / items / enum

Previous value: -[
-  "mercury",
-  "venus"
-]New value: +[
+  "mercury",
+  "venus",
+  "mars",
+  "jupiter",
+  "saturn",
+  "uranus",
+  "neptune"
+]

changedInput schema / properties / bodies / maxItems
```
Previous value: -2New value: +7
```

changedInput schema / properties / date / description

Previous value: -"Anchor instant; with no start/end the response covers the next full synodic cycle from here. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Anchor instant; with no start/end the response covers the next full synodic cycle from here. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Last day of an explicit window, exclusive. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Last day of an explicit window, exclusive. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / kinds / description

Previous value: -"Optional filter of event kinds. Omit for all. peak_magnitude only ever fires for venus; the transit kinds are body-specific and genuinely rare."New value: +"Optional filter of event kinds. Omit for each planet's own family: the seven apparition kinds for mercury and venus, the four Sun-relative kinds for mars to neptune. peak_magnitude only ever fires for venus; the transit kinds are body-specific and genuinely rare. constellation_entry applies to all seven and must be listed."

changedInput schema / properties / kinds / items / enum

Previous value: -[
-  "inferior_conjunction",
-  "superior_conjunction",
-  "greatest_elongation_east",
-  "greatest_elongation_west",
-  "peak_magnitude",
-  "transit_of_mercury",
-  "transit_of_venus"
-]New value: +[
+  "inferior_conjunction",
+  "superior_conjunction",
+  "greatest_elongation_east",
+  "greatest_elongation_west",
+  "peak_magnitude",
+  "transit_of_mercury",
+  "transit_of_venus",
+  "conjunction_with_sun",
+  "quadrature_west",
+  "opposition",
+  "quadrature_east",
+  "constellation_entry"
+]

changedInput schema / properties / start / description

Previous value: -"First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedOutput schema / properties / data / description

Previous value: -"Apparition events per planet in a date range: conjunctions, elongations, stations."New value: +"Planet events in a date range: the Mercury and Venus apparition events (conjunctions, greatest elongations, Venus's peak brightness, transits across the Sun), the Sun-relative events of Mars to Neptune (conjunction with the Sun, quadratures, opposition) and, when asked for, constellation entries. Stations (retrograde turning points) are not among them: astro_planet_board gives each planet's next station, and the full station list is served by the REST route /v2/retrogrades."

Changedastro_positions3 fields changed

changedInput schema / properties / date / description

Previous value: -"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Grid end. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Grid end. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / start / description

Previous value: -"Grid start (use with end and step). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Grid start (use with end and step). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_rise_set3 fields changed

changedInput schema / properties / date / description

Previous value: -"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Last day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Last day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / start / description

Previous value: -"First day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of a daily series. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_sky_today1 field changed

changedInput schema / properties / date / description

Previous value: -"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

Changedastro_sun3 fields changed

changedInput schema / properties / date / description

Previous value: -"Single day to report, ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Single day to report, ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / end / description

Previous value: -"Last day of a range. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"Last day of a range. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

changedInput schema / properties / start / description

Previous value: -"First day of a range (use with end instead of date). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of a range (use with end instead of date). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."

1 tool updateSep 11, 2026

Changedastro_moon3 fields changed

changedOutput schema / properties / data / properties / angular_diameter_arcsec / description

Previous value: -"Apparent disc size in arcseconds."New value: +"Apparent disk size in arcseconds."

changedOutput schema / properties / data / properties / distance_km / description

Previous value: -"Centre-to-centre distance in kilometres."New value: +"Center-to-center distance in kilometres."

changedOutput schema / properties / data / properties / position_geocentric / description

Previous value: -"Position as seen from Earth's centre."New value: +"Position as seen from Earth's center."

11 tool updatesAug 9, 2026

Changedastro_dark_window1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "The best genuinely dark observing windows across a range of nights.",
+      "properties": {
+        "best_night_index": {
+          "description": "Index into `nights` of the best one.",
+          "type": "integer"
+        },
+        "high_latitude_caution": {
+          "description": "True when latitude makes true darkness scarce or absent, so the ranking means less.",
+          "type": "boolean"
+        },
+        "high_latitude_note": {
+          "description": "The explanation when that caution is set.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "method": {
+          "description": "How darkness was defined and how nights were ranked.",
+          "type": "object"
+        },
+        "nights": {
+          "description": "Each night with its dark window and what the Moon does to it.",
+          "type": "array"
+        },
+        "ranked": {
+          "description": "Night indices best to worst.",
+          "type": "array"
+        },
+        "summary": {
+          "description": "The recommendation in brief.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_eclipses1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "Solar and lunar eclipses in a date range, optionally filtered to one location.",
+      "properties": {
+        "eclipse_count": {
+          "description": "How many eclipses matched.",
+          "type": "integer"
+        },
+        "eclipses": {
+          "description": "Each eclipse with its peak instant, kind and Saros series.",
+          "type": "array"
+        },
+        "next_visible": {
+          "description": "Only when a location was given: the next one visible from there, with local circumstances.",
+          "type": "object"
+        },
+        "next_visible_note": {
+          "description": "Only when a location was given: a caveat about that visibility, when one applies.",
+          "type": "string"
+        },
+        "summary": {
+          "description": "A one-line reading of the range.",
+          "type": "string"
+        },
+        "type": {
+          "description": "Which kinds were asked for: solar, lunar or both.",
+          "type": "string"
+        },
+        "window": {
+          "description": "The range actually evaluated.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_find_place1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "Coordinates for a place name, or the nearest named places to coordinates.",
+      "properties": {
+        "found": {
+          "description": "How many are returned here.",
+          "type": "integer"
+        },
+        "index": {
+          "description": "Which place index answered, and its vintage.",
+          "type": "object"
+        },
+        "matched": {
+          "description": "How many places matched before any limit was applied.",
+          "type": "integer"
+        },
+        "mode": {
+          "description": "Whether this was a name search or a reverse lookup.",
+          "type": "string"
+        },
+        "results": {
+          "description": "Each place with coordinates, country, population and a place_id that other tools accept.",
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_moon1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "The Moon's state and appearance, or a sampled series in range mode.",
+      "properties": {
+        "angular_diameter_arcsec": {
+          "description": "Apparent disc size in arcseconds.",
+          "type": "number"
+        },
+        "bright_limb": {
+          "description": "Which way the lit edge points.",
+          "type": "object"
+        },
+        "constellation": {
+          "description": "The IAU constellation the Moon currently occupies.",
+          "type": "object"
+        },
+        "distance_au": {
+          "description": "The same distance in astronomical units.",
+          "type": "number"
+        },
+        "distance_basis": {
+          "description": "Whether the distance is geocentric or topocentric.",
+          "type": "string"
+        },
+        "distance_km": {
+          "description": "Centre-to-centre distance in kilometres.",
+          "type": "number"
+        },
+        "event_definition": {
+          "description": "The altitude convention rise and set are measured against.",
+          "type": "string"
+        },
+        "fraction_of_mean_distance": {
+          "description": "Distance relative to the mean, for supermoon claims.",
+          "type": "number"
+        },
+        "fraction_of_mean_distance_definition": {
+          "description": "How that fraction is defined.",
+          "type": "string"
+        },
+        "libration": {
+          "description": "The rocking that reveals a little of the far side.",
+          "type": "object"
+        },
+        "magnitude": {
+          "description": "Apparent visual brightness.",
+          "type": "number"
+        },
+        "next_phases": {
+          "description": "Upcoming quarter phases with exact instants.",
+          "type": "array"
+        },
+        "parallax_deg": {
+          "description": "Angular shift between those two viewpoints.",
+          "type": "number"
+        },
+        "phase": {
+          "description": "Phase name, angle and illuminated fraction.",
+          "type": "object"
+        },
+        "position_geocentric": {
+          "description": "Position as seen from Earth's centre.",
+          "type": "object"
+        },
+        "position_topocentric": {
+          "description": "Position as seen from the given location.",
+          "type": "object"
+        },
+        "rise_set": {
+          "description": "Moonrise and moonset for the location.",
+          "type": "object"
+        },
+        "series": {
+          "description": "RANGE MODE ONLY: one sampled entry per step.",
+          "type": "array"
+        },
+        "summary": {
+          "description": "A one-line reading of the Moon right now.",
+          "type": "string"
+        },
+        "tropical_sign": {
+          "description": "Tropical ecliptic longitude, reported as position only.",
+          "type": "object"
+        },
+        "window": {
+          "description": "The instant or range actually evaluated.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_moon_phases1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "New, first quarter, full and last quarter moons in a date range.",
+      "properties": {
+        "phase_count": {
+          "description": "How many phases fall in the window.",
+          "type": "integer"
+        },
+        "phases": {
+          "description": "Each phase with its exact instant and name.",
+          "type": "array"
+        },
+        "summary": {
+          "description": "A one-line reading of the range.",
+          "type": "string"
+        },
+        "window": {
+          "description": "The range actually evaluated.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_planet_board1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "Which planets are worth looking at right now, and where.",
+      "properties": {
+        "above_horizon_now": {
+          "description": "Bodies above the horizon, visible or not.",
+          "type": "array"
+        },
+        "bodies": {
+          "description": "Every body with position, brightness and a visibility verdict.",
+          "type": "array"
+        },
+        "count": {
+          "description": "How many bodies are on the board.",
+          "type": "integer"
+        },
+        "instant": {
+          "description": "The moment evaluated.",
+          "type": "string"
+        },
+        "observable_now": {
+          "description": "Bodies both up and realistically visible.",
+          "type": "array"
+        },
+        "retrograde_now": {
+          "description": "Bodies currently in apparent retrograde motion.",
+          "type": "array"
+        },
+        "summary": {
+          "description": "A one-line reading of tonight's planets.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_planet_events1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "Apparition events per planet in a date range: conjunctions, elongations, stations.",
+      "properties": {
+        "bodies": {
+          "description": "One entry per body, each holding its events in time order.",
+          "type": "array"
+        },
+        "body_count": {
+          "description": "How many bodies are covered.",
+          "type": "integer"
+        },
+        "definition": {
+          "description": "How each event kind is defined.",
+          "type": "string"
+        },
+        "event_count": {
+          "description": "How many events matched in total.",
+          "type": "integer"
+        },
+        "kinds_selected": {
+          "description": "The event kinds included.",
+          "type": "array"
+        },
+        "window": {
+          "description": "The range actually evaluated.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_positions1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "Where each requested body is, at an instant or sampled across a range.",
+      "properties": {
+        "bodies": {
+          "description": "SINGLE MODE: one entry per body, with its coordinates.",
+          "type": "array"
+        },
+        "instant": {
+          "description": "SINGLE MODE: the instant evaluated.",
+          "type": "string"
+        },
+        "series": {
+          "description": "RANGE MODE: one sample per step, each holding every body.",
+          "type": "array"
+        },
+        "window": {
+          "description": "RANGE MODE: the range actually evaluated.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_rise_set1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "Rise, transit and set for one body, for a day or across a range.",
+      "properties": {
+        "body": {
+          "description": "SINGLE MODE: the events, with a status covering the polar cases where a body never rises or never sets.",
+          "type": "object"
+        },
+        "days": {
+          "description": "RANGE MODE ONLY: one entry per day.",
+          "type": "array"
+        },
+        "window": {
+          "description": "The day or range actually evaluated.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_sky_today1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "A whole-sky snapshot for one place and moment.",
+      "properties": {
+        "local_date": {
+          "description": "The local calendar date the snapshot describes.",
+          "type": "string"
+        },
+        "moon": {
+          "description": "Phase, illuminated fraction, and rise/set.",
+          "type": "object"
+        },
+        "next_events": {
+          "description": "The next notable sky events, soonest first.",
+          "type": "array"
+        },
+        "night": {
+          "description": "When true darkness begins and ends tonight.",
+          "type": "object"
+        },
+        "planets_down": {
+          "description": "Planets below the horizon now.",
+          "type": "array"
+        },
+        "planets_up": {
+          "description": "Planets above the horizon now, brightest first.",
+          "type": "array"
+        },
+        "summary": {
+          "description": "A one-line plain-language reading of the whole snapshot.",
+          "type": "string"
+        },
+        "sun": {
+          "description": "Sunrise, sunset and the Sun's current position.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedastro_sun1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.",
+  "properties": {
+    "attribution": {
+      "description": "The credit line to display verbatim when rights is attribution_required.",
+      "type": "string"
+    },
+    "data": {
+      "additionalProperties": true,
+      "description": "The complete solar day for one location, or one row per day in range mode.",
+      "properties": {
+        "blue_hour": {
+          "description": "The blue-light window just outside golden hour.",
+          "type": "object"
+        },
+        "constellation": {
+          "description": "The IAU constellation the Sun currently occupies.",
+          "type": "object"
+        },
+        "custom": {
+          "description": "Boundaries for any custom depression angles requested.",
+          "type": "array"
+        },
+        "dark_minutes": {
+          "description": "Minutes of true astronomical darkness.",
+          "type": "integer"
+        },
+        "day_length": {
+          "description": "Day length, human-readable.",
+          "type": "string"
+        },
+        "day_length_change_from_yesterday_seconds": {
+          "description": "Seconds gained or lost since the previous day. Negative means shortening.",
+          "type": "integer"
+        },
+        "day_length_minutes": {
+          "description": "Day length in minutes.",
+          "type": "number"
+        },
+        "day_length_seconds": {
+          "description": "Day length in whole seconds.",
+          "type": "integer"
+        },
+        "days": {
+          "description": "RANGE MODE ONLY: one entry per day, each with the fields above.",
+          "type": "array"
+        },
+        "golden_hour": {
+          "description": "The warm-light window around sunrise and sunset.",
+          "type": "object"
+        },
+        "night_begins": {
+          "description": "When astronomical night starts. Null where it never gets that dark.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "night_ends": {
+          "description": "When astronomical night ends. Null where it never gets that dark.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "position_now": {
+          "description": "Where the Sun is at this moment.",
+          "type": "object"
+        },
+        "rise_set": {
+          "description": "Sunrise and sunset, with a status for polar day and polar night.",
+          "type": "object"
+        },
+        "solar_midnight": {
+          "description": "Instant the Sun is lowest, opposite solar noon.",
+          "type": "string"
+        },
+        "solar_midnight_altitude_deg": {
+          "description": "Sun altitude at solar midnight, in degrees.",
+          "type": "number"
+        },
+        "solar_midnight_altitude_refracted_deg": {
+          "description": "Including refraction.",
+          "type": "number"
+        },
+        "solar_midnight_altitude_unrefracted_deg": {
+          "description": "Geometric, refraction excluded.",
+          "type": "number"
+        },
+        "solar_noon": {
+          "description": "Instant the Sun crosses the meridian.",
+          "type": "string"
+        },
+        "solar_noon_altitude_deg": {
+          "description": "Sun altitude at solar noon, in degrees.",
+          "type": "number"
+        },
+        "solar_noon_altitude_refracted_deg": {
+          "description": "As seen, including atmospheric refraction.",
+          "type": "number"
+        },
+        "solar_noon_altitude_unrefracted_deg": {
+          "description": "Geometric altitude, refraction excluded.",
+          "type": "number"
+        },
+        "solar_noon_azimuth_deg": {
+          "description": "Compass bearing of the Sun at solar noon.",
+          "type": "number"
+        },
+        "summary": {
+          "description": "A one-line reading of the solar day.",
+          "type": "string"
+        },
+        "tropical_sign": {
+          "description": "Tropical ecliptic longitude, reported as position only.",
+          "type": "object"
+        },
+        "twilight": {
+          "description": "Civil, nautical and astronomical twilight boundaries.",
+          "type": "object"
+        },
+        "window": {
+          "description": "The instant or range actually evaluated, after parsing.",
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "next_cursor": {
+      "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.",
+      "type": "string"
+    },
+    "not_computed": {
+      "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".",
+      "type": "array"
+    },
+    "rights": {
+      "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

11 tool updatesAug 9, 2026
- First observedastro_dark_window
- First observedastro_eclipses
- First observedastro_find_place
- First observedastro_moon
- First observedastro_moon_phases
- First observedastro_planet_board
- First observedastro_planet_events
- First observedastro_positions
- First observedastro_rise_set
- First observedastro_sky_today
- First observedastro_sun

Publisher details

Operator: https://www.cyclecalcs.com
Operator website: https://www.cyclecalcs.com
Vendor relationship: Not applicable
Documentation: https://www.cyclecalcs.com/api/mcp.html
Trust center: Not applicable
Restrictions: Not applicable

Related MCP Connectors

astronomy-mcp-server A
io.github.cyanheads
Offline observational astronomy: positions, rise/set, moon phases, eclipses, and seasons.
Aerospace & Astrodynamics Research & Data
713
thirdtrail A
io.github.thirdtrail
Elevation-corrected sun, moon, twilight, solar and tide data for any point on Earth
Weather Services Open Data
81
Kaalshodh — Indian astronomy time machine A
com.kaalshodh
Observatory-grade Indian astronomy, years -5000..+5000: positions, eclipses, panchang date search.
Research & Data Education & Learning Tools Art & Culture
51
FreeAstroAPI Astrology
io.github.GabrielRw
Western, Vedic, and Chinese astrology calculations, charts, forecasts, and geocoding.
Location Services Data Visualization Research & Data
1

Related MCP Servers

astronomy-mcp-server
Aerospace & Astrodynamics Research & Data
cyanheads
A
license
Not graded
quality
A
maintenance
Provides offline astronomical computations for planet and moon positions, rise/set times, phases, eclipses, and seasons via MCP.
Updated 2 days ago (2026-10-08 11:32 UTC)
252 npm
3
Apache 2.0
usno-astronomy
Aerospace & Astrodynamics Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Provides solar eclipse predictions, local eclipse circumstances, Moon phases, and seasons from the US Naval Observatory's Astronomical Applications API.
Updated 14 days ago (2026-09-26 22:11 UTC)
386 npm
MIT
chuk-mcp-celestial
Location Services Weather Services
IBM
A
license
A
quality
F
maintenance
Provides authoritative astronomical data including moon phases, solar eclipses, and sun/moon rise and set times using the US Navy API or offline Skyfield calculations. It enables users to query Earth's seasons and celestial events for any location and date.
Updated 19 days ago (2026-09-21 22:15 UTC)
8
1
Apache 2.0
mcp-stargazing
Weather Services Location Services
StarGazer1995
A
license
A
quality
A
maintenance
Calculate the altitude, rise, and set times of celestial objects (Sun, Moon, planets, stars, and deep-space objects) for any location on Earth.
Updated a month ago (2026-09-07 12:58 UTC)
15
MIT

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?