CycleCalcs Astronomy
Server Details
Read-only astronomy calculations: sun, moon, planets, eclipses, twilight and star positions.
- Status
- Healthy
- Uptime
- 99.9% over 75 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 11 tools
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.
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.
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.
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 toolsastro_dark_windowDark moonless observing windowARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | Night to start from. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| place | No | 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. | |
| nights | No | How many nights to evaluate and rank. Default 1. | |
| moon_illumination_max | No | Treat the Moon as tolerable below this illuminated fraction (0..1) even when up. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The best genuinely dark observing windows across a range of nights. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 eclipsesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Last day of an explicit window. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | Anchor date to search from. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| type | No | Which kind of eclipse to report. Default "both". | |
| count | No | How many eclipses PER TYPE to return. | |
| place | No | 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. | |
| start | No | First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. | |
| include | No | Optional extras, added to the default blocks rather than replacing them. "path": the precomputed central path of a solar eclipse as inline GeoJSON (central line, northern and southern limits, and per-minute duration, width, phase and Sun altitude), for the central eclipses that have one; every other eclipse says why it has none. Large: about 65 to 90 KB of JSON per eclipse, returned as both text and structured content, so ask for one eclipse at a time (type "solar", a date just before it, count 1). "greatest": the circumstances at greatest eclipse from the supplied location, inside each solar eclipse's local block (requires a location). | |
| direction | No | Search direction from the anchor date. Default "next". | |
| visible_only | No | true keeps only eclipses visible from the supplied location (requires a location). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Solar and lunar eclipses in a date range, optionally filtered to one location. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 timezoneARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A place_id from an earlier result, to fetch that exact place. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| limit | No | Maximum matches to return. Default 5. | |
| query | No | 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". | |
| country | No | Two-letter ISO country code filter, e.g. "US". |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Coordinates for a place name, or the nearest named places to coordinates. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 appearanceARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Last day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| count | No | Number of daily rows from start (alternative to end). | |
| place | No | 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. | |
| start | No | First day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The Moon's state and appearance, or a sampled series in range mode. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 calendarARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Last day of a window. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | Anchor date; the next phases follow it. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| count | No | How many phase events to return from the anchor date. | |
| place | No | 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. | |
| start | No | First day of a window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. | |
| phases | No | Optional filter of phase kinds. Omit for all four. Example: ["full_moon"] for full moons only. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | New, first quarter, full and last quarter moons in a date range. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 glanceARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| sort | No | Optional result ordering. Default is by distance from the Sun. | |
| place | No | 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. | |
| bodies | No | Optional subset of planets: mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Which planets are worth looking at right now, and where. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 entriesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Last day of an explicit window, exclusive. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | Anchor instant; with no start/end the response covers the next full synodic cycle from here. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| kinds | No | Optional filter of event kinds. Omit for each planet's own family: the seven apparition kinds for mercury and venus, the four Sun-relative kinds for mars to neptune. peak_magnitude only ever fires for venus; the transit kinds are body-specific and genuinely rare. constellation_entry applies to all seven and must be listed. | |
| place | No | 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. | |
| start | No | First day of an explicit window (use with end). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| bodies | No | Which planets to report. Default mercury and venus. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Planet events in a date range: the Mercury and Venus apparition events (conjunctions, greatest elongations, Venus's peak brightness, transits across the Sun), the Sun-relative events of Mars to Neptune (conjunction with the Sun, quadratures, opposition) and, when asked for, constellation entries. Stations (retrograde turning points) are not among them: astro_planet_board gives each planet's next station, and the full station list is served by the REST route /v2/retrogrades. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 bodiesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Grid end. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| step | No | Grid stride, e.g. "1h", "10min", "1d". | |
| place | No | 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. | |
| start | No | Grid start (use with end and step). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| bodies | Yes | Bodies to report. Each entry: One of sun, moon, mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto, or a fixed J2000 target as "radec:RA,DEC" with RA in hours (0-24) and DEC in degrees (-90..90), e.g. "radec:5.6,-5.4" for the Orion Nebula region. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Where each requested body is, at an instant or sampled across a range. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 timesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Last day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| body | Yes | One of sun, moon, mercury, venus, mars, jupiter, saturn, uranus, neptune, pluto, or a fixed J2000 target as "radec:RA,DEC" with RA in hours (0-24) and DEC in degrees (-90..90), e.g. "radec:5.6,-5.4" for the Orion Nebula region. | |
| date | No | ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| place | No | 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. | |
| start | No | First day of a daily series. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. | |
| search_horizon_days | No | How many days ahead to search when an event does not occur on the requested day (high latitudes). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Rise, transit and set for one body, for a day or across a range. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 momentARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| place | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | A whole-sky snapshot for one place and moment. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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 twilightARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone like "Europe/Lisbon" to render event times in local time. Optional; a resolved place supplies its own timezone. | |
| end | No | Last day of a range. ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| lat | No | Latitude in decimal degrees, north positive. Send lat and lon together. | |
| lon | No | Longitude in decimal degrees, east positive (Lisbon is about -9.14). Send lat and lon together. | |
| date | No | Single day to report, ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| step | No | Range stride in whole days, e.g. "1d", "7d", "30d". Default "1d". | |
| place | No | 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. | |
| start | No | First day of a range (use with end instead of date). ISO 8601 UTC date or datetime, e.g. "2026-08-06" or "2026-08-06T21:00:00Z". 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. | |
| cursor | No | Opaque pagination cursor from a previous result's next_cursor. Send it with the same start/end arguments as the first page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The complete solar day for one location, or one row per day in range mode. |
| rights | No | Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown. |
| warnings | No | Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded. |
| attribution | No | The credit line to display verbatim when rights is attribution_required. |
| next_cursor | No | Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page. |
| not_computed | No | Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as "withheld", never as "none exists". |
TDQS
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.
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.
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.
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.
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.
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.
11 tool updates
- Changed
astro_dark_window1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_eclipses1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_find_place3 fields changed- added
Input schema / anyOfAdded value: +[ + { + "required": [ + "query" + ] + }, + { + "required": [ + "id" + ] + }, + { + "required": [ + "lat", + "lon" + ] + } +] - changed
Input schema / properties / limit / maximumPrevious value: -20New value: +25 - changed
Input schema / properties / query / descriptionPrevious 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\"."
- Changed
astro_moon1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_moon_phases1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_planet_board1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_planet_events1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_positions1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_rise_set1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_sky_today1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
- Changed
astro_sun1 field changed- changed
Input schema / properties / place / descriptionPrevious 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."
10 tool updates
- Changed
astro_dark_window1 field changed- changed
Input schema / properties / date / descriptionPrevious 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."
- Changed
astro_eclipses4 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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." - changed
Output schema / properties / data / properties / eclipses / descriptionPrevious 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."
- Changed
astro_moon3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_moon_phases3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_planet_board1 field changed- changed
Input schema / properties / date / descriptionPrevious 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."
- Changed
astro_planet_events3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_positions3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_rise_set3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_sky_today5 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Output schema / properties / data / properties / planets_down / descriptionPrevious value: -"Planets below the horizon now."New value: +"Planets below the horizon at the request instant." - added
Output schema / properties / data / properties / planets_tonightAdded 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" +} - added
Output schema / properties / data / properties / planets_tonight_basisAdded 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" +} - changed
Output schema / properties / data / properties / planets_up / descriptionPrevious 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."
- Changed
astro_sun3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
10 tool updates
- Changed
astro_dark_window1 field changed- changed
Input schema / properties / date / descriptionPrevious 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."
- Changed
astro_eclipses6 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - added
Input schema / properties / includeAdded 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 +} - changed
Input schema / properties / start / descriptionPrevious 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." - added
Output schema / properties / data / properties / central_geometry_noteAdded value: +{ + "description": "Only when solar eclipses are listed: the lunar-radius convention behind hybrid, the greatest_eclipse fields and the path.", + "type": "string" +} - changed
Output schema / properties / data / properties / eclipses / descriptionPrevious 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."
- Changed
astro_moon3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_moon_phases3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_planet_board1 field changed- changed
Input schema / properties / date / descriptionPrevious 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."
- Changed
astro_planet_events9 fields changed- changed
Input schema / properties / bodies / descriptionPrevious value: -"Which inferior planets to report. Default both."New value: +"Which planets to report. Default mercury and venus." - changed
Input schema / properties / bodies / items / enumPrevious value: -[ - "mercury", - "venus" -]New value: +[ + "mercury", + "venus", + "mars", + "jupiter", + "saturn", + "uranus", + "neptune" +] - changed
Input schema / properties / bodies / maxItemsPrevious value: -2New value: +7 - changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / kinds / descriptionPrevious 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." - changed
Input schema / properties / kinds / items / enumPrevious 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" +] - changed
Input schema / properties / start / descriptionPrevious 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." - changed
Output schema / properties / data / descriptionPrevious 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."
- Changed
astro_positions3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_rise_set3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious 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."
- Changed
astro_sky_today1 field changed- changed
Input schema / properties / date / descriptionPrevious 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."
- Changed
astro_sun3 fields changed- changed
Input schema / properties / date / descriptionPrevious 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." - changed
Input schema / properties / end / descriptionPrevious 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." - changed
Input schema / properties / start / descriptionPrevious value: -"First day of a range (use with end instead of date). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."New value: +"First day of a range (use with end instead of date). ISO 8601 UTC date or datetime, e.g. \"2026-08-06\" or \"2026-08-06T21:00:00Z\". Or jd: followed by a Julian Day on the UT scale, e.g. \"jd:2461000.5\". On astro_positions, date may list up to 24 datetimes separated by commas, answered in the order sent. Omit for the current moment. Years 1700 to 2200 only; outside that range the API refuses with DATE_OUT_OF_RANGE because the ephemeris is not reliable there."
1 tool update
- Changed
astro_moon3 fields changed- changed
Output schema / properties / data / properties / angular_diameter_arcsec / descriptionPrevious value: -"Apparent disc size in arcseconds."New value: +"Apparent disk size in arcseconds." - changed
Output schema / properties / data / properties / distance_km / descriptionPrevious value: -"Centre-to-centre distance in kilometres."New value: +"Center-to-center distance in kilometres." - changed
Output schema / properties / data / properties / position_geocentric / descriptionPrevious value: -"Position as seen from Earth's centre."New value: +"Position as seen from Earth's center."
11 tool updates
- Changed
astro_dark_window1 field changed- changed
Output 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" +}
- Changed
astro_eclipses1 field changed- changed
Output 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" +}
- Changed
astro_find_place1 field changed- changed
Output 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" +}
- Changed
astro_moon1 field changed- changed
Output 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" +}
- Changed
astro_moon_phases1 field changed- changed
Output 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" +}
- Changed
astro_planet_board1 field changed- changed
Output 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" +}
- Changed
astro_planet_events1 field changed- changed
Output 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" +}
- Changed
astro_positions1 field changed- changed
Output 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" +}
- Changed
astro_rise_set1 field changed- changed
Output 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" +}
- Changed
astro_sky_today1 field changed- changed
Output 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" +}
- Changed
astro_sun1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The MCP projection of a CycleCalcs v2 response: the answer, plus the provenance a caller needs to use it honestly.", + "properties": { + "attribution": { + "description": "The credit line to display verbatim when rights is attribution_required.", + "type": "string" + }, + "data": { + "additionalProperties": true, + "description": "The complete solar day for one location, or one row per day in range mode.", + "properties": { + "blue_hour": { + "description": "The blue-light window just outside golden hour.", + "type": "object" + }, + "constellation": { + "description": "The IAU constellation the Sun currently occupies.", + "type": "object" + }, + "custom": { + "description": "Boundaries for any custom depression angles requested.", + "type": "array" + }, + "dark_minutes": { + "description": "Minutes of true astronomical darkness.", + "type": "integer" + }, + "day_length": { + "description": "Day length, human-readable.", + "type": "string" + }, + "day_length_change_from_yesterday_seconds": { + "description": "Seconds gained or lost since the previous day. Negative means shortening.", + "type": "integer" + }, + "day_length_minutes": { + "description": "Day length in minutes.", + "type": "number" + }, + "day_length_seconds": { + "description": "Day length in whole seconds.", + "type": "integer" + }, + "days": { + "description": "RANGE MODE ONLY: one entry per day, each with the fields above.", + "type": "array" + }, + "golden_hour": { + "description": "The warm-light window around sunrise and sunset.", + "type": "object" + }, + "night_begins": { + "description": "When astronomical night starts. Null where it never gets that dark.", + "type": [ + "string", + "null" + ] + }, + "night_ends": { + "description": "When astronomical night ends. Null where it never gets that dark.", + "type": [ + "string", + "null" + ] + }, + "position_now": { + "description": "Where the Sun is at this moment.", + "type": "object" + }, + "rise_set": { + "description": "Sunrise and sunset, with a status for polar day and polar night.", + "type": "object" + }, + "solar_midnight": { + "description": "Instant the Sun is lowest, opposite solar noon.", + "type": "string" + }, + "solar_midnight_altitude_deg": { + "description": "Sun altitude at solar midnight, in degrees.", + "type": "number" + }, + "solar_midnight_altitude_refracted_deg": { + "description": "Including refraction.", + "type": "number" + }, + "solar_midnight_altitude_unrefracted_deg": { + "description": "Geometric, refraction excluded.", + "type": "number" + }, + "solar_noon": { + "description": "Instant the Sun crosses the meridian.", + "type": "string" + }, + "solar_noon_altitude_deg": { + "description": "Sun altitude at solar noon, in degrees.", + "type": "number" + }, + "solar_noon_altitude_refracted_deg": { + "description": "As seen, including atmospheric refraction.", + "type": "number" + }, + "solar_noon_altitude_unrefracted_deg": { + "description": "Geometric altitude, refraction excluded.", + "type": "number" + }, + "solar_noon_azimuth_deg": { + "description": "Compass bearing of the Sun at solar noon.", + "type": "number" + }, + "summary": { + "description": "A one-line reading of the solar day.", + "type": "string" + }, + "tropical_sign": { + "description": "Tropical ecliptic longitude, reported as position only.", + "type": "object" + }, + "twilight": { + "description": "Civil, nautical and astronomical twilight boundaries.", + "type": "object" + }, + "window": { + "description": "The instant or range actually evaluated, after parsing.", + "type": "object" + } + }, + "type": "object" + }, + "next_cursor": { + "description": "Present only when more rows exist. Send it back with the SAME start/end arguments as the first call to get the next page.", + "type": "string" + }, + "not_computed": { + "description": "Data this API deliberately does not serve, and why. Present only when the question touched such a field. An absence named here is information: treat it as \"withheld\", never as \"none exists\".", + "type": "array" + }, + "rights": { + "description": "Either unrestricted, or attribution_required when third-party place data was used. When attribution_required, the attribution line must be shown.", + "type": "string" + }, + "warnings": { + "description": "Machine-readable notices about this answer. Present only when non-empty. Never changes whether the call succeeded.", + "type": "array" + } + }, + "required": [ + "data" + ], + "type": "object" +}
11 tool updates
- First observed
astro_dark_window - First observed
astro_eclipses - First observed
astro_find_place - First observed
astro_moon - First observed
astro_moon_phases - First observed
astro_planet_board - First observed
astro_planet_events - First observed
astro_positions - First observed
astro_rise_set - First observed
astro_sky_today - First observed
astro_sun
Publisher details
- Operator
- https://www.cyclecalcs.com
- Operator website
- https://www.cyclecalcs.com
- Vendor relationship
- Not applicable
- Documentation
- https://www.cyclecalcs.com/api/mcp.html
- Trust center
- Not applicable
- Restrictions
- Not applicable
Related MCP Connectors
Offline observational astronomy: positions, rise/set, moon phases, eclipses, and seasons.
Elevation-corrected sun, moon, twilight, solar and tide data for any point on Earth
Observatory-grade Indian astronomy, years -5000..+5000: positions, eclipses, panchang date search.
Sunrise, sunset, twilight, golden hour and moon times for any place on Earth. Free, no API key.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceProvides offline astronomical computations for planet and moon positions, rise/set times, phases, eclipses, and seasons via MCP.690 npm3Apache 2.0
- AlicenseNot gradedqualityBmaintenanceProvides solar eclipse predictions, local eclipse circumstances, Moon phases, and seasons from the US Naval Observatory's Astronomical Applications API.7 npm1MIT
- AlicenseAqualityFmaintenanceProvides 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.81Apache 2.0
- AlicenseAqualityAmaintenanceCalculate the altitude, rise, and set times of celestial objects (Sun, Moon, planets, stars, and deep-space objects) for any location on Earth.21128 PyPIMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.