Skip to main content
Glama

Server Details

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

Ownership verified
Status
Healthy
Uptime
99.9% over 75 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 11 tools

Disambiguation4/5

Most tools are clearly separated by resource and action, and the descriptions explicitly route ambiguous cases (e.g. astro_moon vs astro_moon_phases, astro_positions vs astro_rise_set). The main overlap is between the broad astro_sky_today aggregator and specialized tools like astro_planet_board, astro_sun, and astro_dark_window, but guidance reduces misselection.

Naming Consistency5/5

All tools use the same astro_ snake_case prefix pattern with clear domain-oriented names. The one verb-style name, astro_find_place, still fits the convention and is not confusing.

Tool Count5/5

Eleven tools is well-scoped for an astronomy calculation/observing-planning server. There are both broad snapshot tools and specialized calculators, and each appears to earn its place.

Completeness5/5

The surface covers the main observing-planning lifecycle: place resolution, Sun/Moon/planet state, rise/set times, exact positions, dark windows, eclipses, planet events, and broad sky snapshots. No obvious dead ends for the apparent solar-system observing domain.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoNight to start from. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
nightsNoHow many nights to evaluate and rank. Default 1.
moon_illumination_maxNoTreat the Moon as tolerable below this illuminated fraction (0..1) even when up.

Output Schema

NameRequiredDescription
dataYesThe best genuinely dark observing windows across a range of nights.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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.3/5.0
Behavior3/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 the safety profile is covered. The description adds that results are ranked across up to 62 nights with a trend and that a location is mandatory — useful beyond the annotations — but says nothing about timezone/attribution behavior or the empties (e.g. nights with no astronomical darkness), which matters at high latitudes.

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 sentences, front-loaded with the definition, then selection guidance, then the exclusion. Nothing is redundant and the ordering matches how an agent decides whether to call.

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 described, annotations cover safety, and the schema documents all seven parameters. Combined with the description's purpose, intents, location prerequisite, and sibling routing, 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 coverage is 100%, so baseline 3 applies; the schema already explains tz, lat/lon, date, nights, and moon_illumination_max in detail. The description's only added semantic is 'Location required', which usefully flags the anyOf constraint, but it does not explain nights ranking or the moon tolerance beyond what the schema says.

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 composite resource — astronomical night intersected with the Moon being down — plus scope (ranked across up to 62 nights with a trend). It explicitly names the sibling it is not (astro_sun for plain twilight times), so an 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 user intents it serves (stargazing, Milky Way photography, deep-sky observing) and an explicit alternative with the condition that selects it: 'For plain twilight times use astro_sun.' It also states the location prerequisite up front.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoLast day of an explicit window. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoAnchor date to search from. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
typeNoWhich kind of eclipse to report. Default "both".
countNoHow many eclipses PER TYPE to return.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoFirst 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". With a location, a bare date means that date there: its day, its evening and its night. 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.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.
includeNoOptional 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).
directionNoSearch direction from the anchor date. Default "next".
visible_onlyNotrue keeps only eclipses visible from the supplied location (requires a location).

Output Schema

NameRequiredDescription
dataYesSolar and lunar eclipses in a date range, optionally filtered to one location.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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
Behavior4/5

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

Annotations already cover read-only, idempotent, closed-world safety, so the description is free to spend its words on what annotations cannot express: the per-type counting quirk (count=3 with type "both" yields six events) and the distinction between global and location-dependent output (local circumstances, contact times, an explicit visible-from-here flag). The only gap is that the heavy payload warning for the path include lives in the schema rather than the description.

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

Conciseness4/5

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

One front-loaded paragraph that moves from core modes to output fields to location behavior to the counting caveat, with no filler sentences. It is dense and long, but every clause carries information an agent would otherwise have to infer.

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?

For a 13-parameter, output-schema-backed astronomy query tool, the description covers the mode selection, the optional location path, the include extras, and the main footgun. Pagination (cursor), the 1700-2200 year bound, and payload sizing are left to the schema, which is acceptable given those fields are fully documented there.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description restates the include, visible_only, and type semantics that the schema already spells out at length, adding only the concrete count-per-type example; it does not explain direction anchoring or start/end interplay beyond what the schema says.

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 pair (solar and lunar eclipses) and immediately enumerates the three retrieval modes: next from a date, previous from a date, and all in a range. It also lists the returned data (type, magnitude, obscuration, Saros series, geometry), so an agent knows exactly what it gets 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?

Gives concrete operational guidance: use direction for next/previous, start/end for a range, set visible_only to true to keep only locally visible events, and use include to add path or greatest-eclipse blocks. It stops short of naming exclusion cases or pointing at sibling tools, but the siblings are different resources so the risk of misrouting is low.

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.

NameRequiredDescriptionDefault
idNoA place_id from an earlier result, to fetch that exact place.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
limitNoMaximum matches to return. Default 5.
queryNoThe place NAME to search for, one to three words, e.g. "Springfield" or "Springfield,US". Never a question or a sentence: send "Lisbon", not "moon phase tonight in Lisbon".
countryNoTwo-letter ISO country code filter, e.g. "US".

Output Schema

NameRequiredDescription
dataYesCoordinates for a place name, or the nearest named places to coordinates.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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/closed-world, so the safety bar is low. The description adds genuinely non-structured context: results are GeoNames data under CC BY 4.0 and the attribution field must be preserved when shown, plus that place_id is stable and reusable in the `id` parameter. No pagination or error behavior mentioned, hence not 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?

Three sentences, front-loaded with capabilities, then licensing obligation, then the routing note — no filler. The attribution sentence is slightly heavy but carries a real compliance requirement, so it earns its space.

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?

Covers all three invocation modes, the data source and licensing obligation, the stable-id round-trip, and when to prefer siblings. With a full output schema and full annotation coverage, nothing an agent needs to call this correctly 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 coverage is 100% with clear per-field descriptions (including the anyOf-required groups), so baseline is 3. The description adds mode-level semantics beyond the schema: it explains that the three shapes are name-lookup, id-fetch, and reverse geocode, and that the name lookup is what you need to disambiguate or country-filter.

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 ('Resolve a place name to coordinates, region, country, IANA timezone and a stable place_id') and covers the reverse direction ('reverse-look-up the nearest places to a lat/lon'), i.e. all three input modes. It also names the sibling class ('the other tools accept a place argument directly'), so an agent can tell this apart from astro_rise_set, astro_positions, etc.

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-not guidance: this tool 'is only needed to disambiguate a name, filter by country, or reverse-geocode', implying other tools take a place directly. That is the exact routing decision an agent faces against the ten sibling tools.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoLast day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
countNoNumber of daily rows from start (alternative to end).
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoFirst day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

NameRequiredDescription
dataYesThe Moon's state and appearance, or a sampled series in range mode.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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 the safety profile is covered and the description doesn't need to repeat it. The description still adds real behavioral context: the instant-vs-series duality, and that a location changes the output set (rise/set, altitude). It doesn't mention the pagination flow or error behavior, which are documented 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 tight sentences: capability first, location behavior second, sibling disambiguation last. No filler, no restatement of the title, and the most decision-relevant routing information is placed where it will be seen.

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 values need no explanation, and the rich 100%-covered parameter schema handles dates, place, count, and pagination. For a read-only astronomy query tool, nothing an agent needs 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3 even with no parameter prose. The description nonetheless adds value by explaining that location parameters unlock additional outputs (rise/set, altitude), which is a semantic link the schema descriptions don't make explicit.

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 the specific resource (the Moon) and the two modes it serves (instant or daily series), then enumerates the exact quantities returned: phase name and angle, illuminated fraction, distance, apparent size, libration, bright limb, next quarters. It explicitly distinguishes itself from astro_moon_phases and astro_positions, so an agent can route without opening a schema.

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

Usage Guidelines4/5

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

Explicitly names two alternatives and the condition that selects each (calendar of new/full moons → astro_moon_phases; exact coordinates → astro_positions), and notes that supplying a location adds rise/set and altitude. It stops short of routing rise/set requests to the astro_rise_set sibling, which is a small remaining gap.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoLast day of a window. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoAnchor date; the next phases follow it. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
countNoHow many phase events to return from the anchor date.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoFirst day of a window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.
phasesNoOptional filter of phase kinds. Omit for all four. Example: ["full_moon"] for full moons only.

Output Schema

NameRequiredDescription
dataYesNew, first quarter, full and last quarter moons in a date range.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower, but the description still adds real context beyond them: dual supermoon definitions, eclipse annotation on events, and a licensing obligation to preserve the GeoNames CC BY 4.0 attribution when a place is used. It does not mention pagination limits or rate behavior, which keeps it from a 5.

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

Conciseness5/5

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

Three sentences, front-loaded with the enumeration of phase events and their payload before moving to usage and the sibling redirect. No filler or restatement of the name/title.

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, yet the description still summarizes the returned fields and flags the attribution requirement, and it covers both window and count-based invocation alongside the sibling distinction. Nothing an agent needs to call this correctly 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: it frames the two mutually exclusive modes (start/end window versus date plus count for "the next few"). That resolves a genuine ambiguity in how the 10 optional parameters combine.

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 and verb: enumerates the phase kinds (new moon, quarter, full moon) within a window or following a date, and specifies the per-event payload (instant, distance, apparent size, supermoon classification, traditional name, eclipse). It explicitly distinguishes itself from astro_moon, so an agent can separate the two without opening a schema.

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

Usage Guidelines5/5

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

Gives a concrete use case ("when is the next full moon", phase calendars) and names the alternative tool with the condition that selects it: "For the Moon's state right now use astro_moon." Both the when and the when-not are present.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
sortNoOptional result ordering. Default is by distance from the Sun.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
bodiesNoOptional subset of planets: mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto.

Output Schema

NameRequiredDescription
dataYesWhich planets are worth looking at right now, and where.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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 the safety profile is covered. The description adds value by disclosing the breadth of evaluation performed server-side (visibility judgement, retrograde station) that the agent would otherwise have to assume. It does not mention the GeoNames attribution constraint, but the schema already carries that, so this is a minor gap rather than a contradiction.

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?

Roughly three sentences, front-loaded with the payload contents before the routing rule. Every clause carries selection value: the field list makes the tool's richness apparent, and the sibling reference prevents misfires.

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?

Zero required parameters, a fully described schema and an output schema mean the description only has to sell the tool's purpose and routing, which it does decisively. Nothing an agent needs 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% and every parameter (tz, lat/lon pairing, date formats and year bounds, sort enum, place format, bodies subset) is fully documented in the schema itself. The description adds no parameter-level guidance such as default location behaviour when neither place nor lat/lon is sent, 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 resource (all eight planets) in one call and enumerates exactly what each entry contains: constellation, magnitude, size, elongation, morning/evening, retrograde with next station, rise/set, and a visibility assessment. It explicitly contrasts with astro_positions for precise coordinates of individual bodies, so an agent can distinguish it from siblings without opening a schema.

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

Usage Guidelines5/5

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

Gives a concrete selection rule: "The right tool for 'which planets are visible tonight'" plus an explicit alternative ("For exact coordinates of specific bodies use astro_positions"). Both the when-to-use and the when-to-use-something-else are stated outright.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoLast day of an explicit window, exclusive. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoAnchor 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". With a location, a bare date means that date there: its day, its evening and its night. 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.
kindsNoOptional 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.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoFirst 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". With a location, a bare date means that date there: its day, its evening and its night. 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.
bodiesNoWhich planets to report. Default mercury and venus.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

NameRequiredDescription
dataYesPlanet 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.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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 already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description goes well beyond that by explaining the no-date fallback (current cycle position for Mercury/Venus), the Mercury peak-brightness caveat, the classical heliocentric convention for Mercury/Venus conjunctions, and the requirement to list constellation_entry explicitly.

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?

The description is front-loaded and every clause defines a meaningful event family or usage rule. However, several very long sentences pack multiple concepts together, making it denser than necessary for an agent scanning for selection criteria.

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, full schema coverage, and rich annotations, the description supplies the remaining selection and behavioral context an agent needs. It covers event families, defaults, exceptions, sibling routing, and conventions without leaving material gaps.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents each parameter thoroughly. The description adds some semantic nuance around kinds (e.g., peak_magnitude only fires for Venus, transit kinds are body-specific), but this largely mirrors the detailed kinds parameter description and does not significantly extend 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?

The description opens with a specific verb-and-resource statement ('Dated planet events') and enumerates exactly which event families are covered for Mercury/Venus versus the outer planets. It explicitly distinguishes itself from astro_planet_board by naming the sibling and its different purpose.

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 names concrete use cases ('when does Venus become the morning star', 'when is Mars at opposition') and routes tonight's all-planet visibility to astro_planet_board. It also explains when constellation_entry appears and which event kinds are omitted by default.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoGrid end. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
stepNoGrid stride, e.g. "1h", "10min", "1d".
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoGrid start (use with end and step). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
bodiesYesBodies 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.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

NameRequiredDescription
dataYesWhere each requested body is, at an instant or sampled across a range.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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
Behavior3/5

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

The read-only/idempotent safety profile is already carried by annotations, and the description still adds real behavioral context: topocentric vs geocentric frame switching with a location, refraction flagged per field, meta.conventions.label_origin, the GeoNames attribution that must be preserved, and DATE_OUT_OF_RANGE outside 1700-2200. That is genuinely useful beyond the annotations, but the description never mentions the pagination cursor's role or the shape of grid results, so it is solid rather than complete.

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?

Front-loads what is returned, then the frame caveat, then the routing rules in two short refusals. Dense but every clause carries information an agent needs; no filler or restatement of the title.

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?

With a full output schema and annotations present, the description covers the non-obvious semantics (frames, refraction, attribution, date bounds). The remaining gap is the grid/pagination interplay (start/end/step vs cursor), which is left entirely to 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 coverage is 100% and the parameter descriptions are unusually rich (date/jd formats, comma lists up to 24 datetimes, body list including radec: syntax, place vs lat/lon), so the schema does the heavy lifting. The tool description adds only the topocentric-vs-geocentric consequence of supplying a location, which is a modest complement to the schema rather than new parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (exact positions for up to 20 bodies) and enumerates the returned quantities: RA/Dec in J2000 and of-date, ecliptic lon/lat, distance, altitude/azimuth with refraction. It also names the sibling tools it is not (astro_rise_set, astro_planet_board), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Explicit selection rule: 'Use for "where exactly is X"', plus two named alternatives with the conditions that select them (rise/set TIMES, all-planet visibility overview). It also states a negative constraint, 'Do not pass earth', which is the main misuse to guard against.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoLast day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
bodyYesOne 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.
dateNoISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoFirst day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.
search_horizon_daysNoHow many days ahead to search when an event does not occur on the requested day (high latitudes).

Output Schema

NameRequiredDescription
dataYesRise, transit and set for one body, for a day or across a range.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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?

The annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful behavioral detail beyond them: extreme latitudes return explicit circumpolar or never-rises statuses rather than missing values, and fixed radec targets are accepted.

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?

The description is front-loaded with the core purpose, then adds the extreme-latitude behavior and sibling routing in two compact follow-up sentences. Every sentence contributes useful selection or behavior information with no obvious filler.

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?

With rich annotations, a detailed input schema, and an output schema, the description covers the key purpose, special extreme-latitude behavior, radec support, and main alternatives. It could mention series or pagination behavior, but those are already handled by the schema and 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 the ten parameters in detail. The description adds only high-level context such as one body at one location and radec target support, which is consistent with the baseline of 3 when the schema carries parameter semantics.

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 specific resource and operation: rise, upper transit, set, and lower transit for one body at one location. It also names distinguishing capabilities such as explicit extreme-latitude statuses and fixed radec targets, which lets an agent separate it from nearby astronomy tools.

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?

It explicitly routes the Sun case to astro_sun for richer twilight structure and routes between-event positions to astro_positions. That is clear alternative-selection guidance, though it does not enumerate all other sibling tools such as astro_moon or astro_planet_events.

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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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

NameRequiredDescription
dataYesA whole-sky snapshot for one place and moment.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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 genuine behavioral context beyond that: it aggregates eclipse, planet and lunar data in a single call, and that payload varies with whether a location is supplied ('with a location, sun times'). It stops short of describing response size or the attribution-preservation obligation, which lives only 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 sentences, zero waste: capability first, then the primary selection cue, then the exclusion routing. Every clause earns its place and the most important guidance is front-loaded.

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-shape explanation is unnecessary; annotations carry the safety profile; the schema carries parameter detail. The description supplies exactly the decision layer the structured fields cannot: what it covers and how to choose it over nine siblings.

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%, including the place-vs-lat/lon distinction, the ISO/JD date formats and the 1700-2200 range, so the schema does the heavy lifting. The description only echoes the optionality of location via '(with a location)'. 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 verb and resource ('One-call snapshot of the whole sky for a place and moment') and enumerates the contents: moon phase and illumination, visible planets, next eclipse, sun times. This is clearly distinguishable from the single-topic siblings it 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?

Explicitly routes broad questions here ('Reach for this first when the question is broad, like "what is in the sky tonight"') and names three alternatives with the exact condition that selects each: astro_sun for solar-day detail, astro_dark_window for choosing 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.

NameRequiredDescriptionDefault
tzNoIANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone.
endNoLast day of a range. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
latNoLatitude in decimal degrees, north positive. Send lat and lon together.
lonNoLongitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together.
dateNoSingle day to report, ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". With a location, a bare date means that date there: its day, its evening and its night. 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.
stepNoRange stride in whole days, e.g. "1d", "7d", "30d". Default "1d".
placeNoThe place NAME only, one to three words, instead of lat/lon: "City" or "City,CC" with an ISO country code, e.g. "Lisbon,PT". Never a question or a sentence. 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.
startNoFirst 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". With a location, a bare date means that date there: its day, its evening and its night. 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.
cursorNoOpaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page.

Output Schema

NameRequiredDescription
dataYesThe complete solar day for one location, or one row per day in range mode.
rightsNoEither unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.
warningsNoMachine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.
attributionNoThe credit line to display verbatim when rights is attribution_required.
next_cursorNoPresent only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.
not_computedNoData 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.4/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 the description correctly spends its words elsewhere: it discloses that polar day/night status is returned explicitly at high latitudes, which is non-obvious behavior an agent would otherwise mis-handle. It does not mention pagination behavior or response shape, but an output schema exists, so that is a minor gap.

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 range-mode requirement, then sibling routing. Every clause carries information an agent needs, with no filler.

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?

For a 9-parameter tool with an output schema and full annotations, the description covers purpose, precondition, range mode, and disambiguation adequately. Pagination via cursor and the place-name constraint are left entirely to the schema, which handles them, so the omission is small but real.

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

Parameters3/5

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

Schema description coverage is 100% and the step/start/end/place semantics are already thoroughly documented in the schema. The description only restates the range pattern ('step is whole days, e.g. "1d" or "7d"') and the location requirement, adding no syntax or format detail beyond the schema. 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 verb+resource with enumerated outputs: sunrise, sunset, solar noon, day length, three twilight boundaries, and polar day/night status. It is clearly distinguishable from siblings because it names astro_dark_window and astro_sky_today as different entry points for different questions.

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 routing: a series requires start+end with a whole-day step; 'is it dark enough to observe' goes to astro_dark_window; a broad snapshot goes to astro_sky_today. It also states the hard precondition (location required), which is the most likely failure mode for this tool.

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.

  1. 11 tool updates
    • Changedastro_dark_window1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_eclipses1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_find_place3 fields changed
      • addedInput schema / anyOf
        Added value: +[
        +  {
        +    "required": [
        +      "query"
        +    ]
        +  },
        +  {
        +    "required": [
        +      "id"
        +    ]
        +  },
        +  {
        +    "required": [
        +      "lat",
        +      "lon"
        +    ]
        +  }
        +]
      • changedInput schema / properties / limit / maximum
        Previous value: -20New value: +25
      • changedInput schema / properties / query / description
        Previous value: -"Place name to search for, e.g. \"Springfield\"."New value: +"The place NAME to search for, one to three words, e.g. \"Springfield\" or \"Springfield,US\". Never a question or a sentence: send \"Lisbon\", not \"moon phase tonight in Lisbon\"."
    • Changedastro_moon1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_moon_phases1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_planet_board1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_planet_events1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_positions1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_rise_set1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_sky_today1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
    • Changedastro_sun1 field changed
      • changedInput schema / properties / place / description
        Previous value: -"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."New value: +"The place NAME only, one to three words, instead of lat/lon: \"City\" or \"City,CC\" with an ISO country code, e.g. \"Lisbon,PT\". Never a question or a sentence. 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."
  2. 10 tool updates
    • 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\". 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."New value: +"Night to start from. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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_eclipses4 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\". 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."New value: +"Anchor date to search from. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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 / properties / eclipses / description
        Previous 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."New value: +"Each eclipse with its peak instant, kind and Saros series. peak is greatest eclipse for the whole Earth; with a location, a solar row's local block gives the kind, magnitude and maximum_instant where you are. 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\". 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."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."New value: +"Last day of a window. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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_events3 fields changed
      • 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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_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\". 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."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."New value: +"Grid end. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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_today5 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\". 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."New value: +"ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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 / properties / planets_down / description
        Previous value: -"Planets below the horizon now."New value: +"Planets below the horizon at the request instant."
      • addedOutput schema / properties / data / properties / planets_tonight
        Added value: +{
        +  "description": "Planets above this horizon after civil dusk ends or before civil dawn begins, brightest first, with the altitude each verdict was decided on. The list to answer \"what can I see tonight\" from; planets_up is not.",
        +  "type": "array"
        +}
      • addedOutput schema / properties / data / properties / planets_tonight_basis
        Added value: +{
        +  "description": "The civil dusk and civil dawn instants planets_tonight was sampled at, the solar altitude that defines them, and the kind of night (normal, never_dark, dark_all_day).",
        +  "type": "object"
        +}
      • changedOutput schema / properties / data / properties / planets_up / description
        Previous value: -"Planets above the horizon now, brightest first."New value: +"Planets above the horizon at the request instant, brightest first, daylight included; each carries observable_tonight and a visibility phrase checked against this horizon at civil dusk and dawn."
    • 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\". 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."New value: +"Single day to report, ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."New value: +"Last day of a range. ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". With a location, a bare date means that date there: its day, its evening and its night. 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\". 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."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\". With a location, a bare date means that date there: its day, its evening and its night. 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."
  3. 10 tool updates
    • 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."
  4. 1 tool update
    • 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."
  5. 11 tool updates
    • 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"
        +}
  6. 11 tool updates
    • 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
Vendor relationship
Not applicable
Trust center
Not applicable
Restrictions
Not applicable

Related MCP Connectors

Related MCP Servers

  • 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.
    7 npm
    1
    MIT
  • 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.
    8
    1
    Apache 2.0
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources