Astrology, Vedic, Chinese and Maya calendar maths on real engines, cited in every answer.
Scored across 18 tools
Most tools have clearly distinct domains: natal charts, transits, planetary positions, panchang, calendars, eclipses, and divination systems. The main overlaps are check_retrogrades versus get_planetary_positions for retrograde questions, and compute_maya_day_sign versus convert_calendar_date for Maya date conversions, but the descriptions give enough detail to usually pick correctly.
All tool names use snake_case and follow an actionable verb_noun structure: compute_*, convert_*, get_*, find_*, check_*, and resolve_*. The verbs are varied but semantically predictable, with no camelCase mixing or vague standalone names.
Eighteen tools is on the heavy side, but the server covers a very broad range of astrological, calendrical, and divinatory calculators, so most tools earn their place. It is slightly over a tightly scoped set but not excessive for this wide calculator surface.
The surface covers a remarkable range of traditions and use cases, including Western and Vedic astrology, Chinese calendrics, Maya calendars, eclipses, panchang, tarot birth cards, and I Ching text lookup. Some gaps remain, such as no general tarot card lookup/meaning tool and no standalone natal aspect grid, but agents can work around most of these.
Reports which planets are retrograde on a date and the two stations that open and close each body's current period ("since 2026-02-14, until 2026-03-07"). Per body: retrograde flag, ecliptic longitude, longitude speed, sign and degree, and both stations with exact UTC instants.
The dates shift every cycle and follow no fixed calendar rule; Mercury stations retrograde three or four times a year. A station is where longitude speed crosses zero, found by bisection for eight bodies, so this takes longer than a single-instant position.
Excluded: the Sun and Moon, which cannot station, and Rahu and Ketu, whose mean motion is backwards throughout. The "excluded" array lists them.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-03-01". Defaults to today (UTC). | |
| time | No | Time of day HH:MM, read as UTC. Example: "12:00". Matters within a day of a station. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent and closed-world, and the description goes well beyond them: it discloses the computation method (zero-crossing of longitude speed found by bisection for eight bodies), warns that it is slower than a single-instant position call, and enumerates what the response contains including attribution and permalink. Auth, cost and output shape questions are all pre-empted.
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 short paragraphs, front-loaded with the return contents, then the cost/model note, then exclusions and metadata. Every sentence carries information an agent needs; nothing is padding.
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?
No output schema exists, yet the description enumerates the per-body fields (retrograde flag, longitude, speed, sign, degree, both stations in UTC) plus the excluded array and attribution/permalink. Combined with annotations, an agent has everything needed to call it and interpret the result.
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 date format, range and default are already fully documented, and the description's note that time matters within a day of a station largely restates the schema. The one value-add, that station dates shift each cycle with no fixed calendar rule, explains why results vary rather than adding parameter syntax.
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 (reports which planets are retrograde) plus the distinctive extra scope: the two stations opening and closing each body's current period. That is enough to tell it apart from get_planetary_positions and compute_transits without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is clear scoping guidance — the Sun/Moon and Rahu/Ketu are excluded and surfaced in an 'excluded' array — plus a note that time matters within a day of a station and that the date defaults to today. However, no sibling is named as an alternative, so the agent must infer that get_planetary_positions is the right tool when only plain positions are wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Casts a natal chart: each planet's sign and exact degree in both the tropical (Western) and sidereal (Vedic, Lahiri) zodiacs, the ascendant, the twelve Placidus cusps, the midheaven, retrograde state and the Moon's nakshatra. It covers any chart, rising sign, Moon sign or planet-in-house. Takes a birth date (1800-2200) and a place.
The chart uses the UTC offset in force at that place on that date (East Tennessee kept Central time until 1947), and an hour's error moves the ascendant about 15 degrees, usually into another sign, with the houses following. With "time" left out for an unknown birth time, the ascendant, cusps and houses are withheld, because a stand-in time such as noon gives a wrong ascendant.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours. Example: "America/Indiana/Indianapolis" or "-5". When absent, resolved for the birth date. | |
| lat | No | Latitude in decimal degrees as a string. Example: "39.76838". Paired with lon. | |
| lon | No | Longitude in decimal degrees as a string. Example: "-86.15804". Paired with lat. | |
| date | Yes | Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". Other formats such as "19/10/1977" are refused. | |
| time | No | Birth time HH:MM, 24-hour, local at the birthplace. Example: "23:58". Optional; when it is absent the ascendant and houses are withheld. | |
| place | No | Town or city of birth with region and country. Example: "Indianapolis, Indiana, United States". A bare "Springfield" is refused with candidates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, and the description still adds substantial behavior: historical UTC offset resolution ('East Tennessee kept Central time until 1947'), the ±15° ascendant sensitivity to a one-hour error, and the deliberate degradation when time is omitted (ascendant, cusps and houses withheld rather than substituted with noon). It also notes the attribution line and permalink in results.
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-loaded with outputs before caveats, which is the right order. There is some duplication with the schema (the 1800-2200 range and the withheld-houses rule appear in both), costing a bit of tightness.
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 no output schema, the description fully enumerates the return payload and adds the attribution/permalink tail. For a six-parameter compute tool it also covers the two ways the call degrades (missing time, ambiguous place) so an agent knows what to expect back.
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 carries parameter meaning and baseline 3 applies. The description reinforces the time-omission consequence and date range, but largely restates what the schema says ('when it is absent the ascendant and houses are withheld'); it adds no new syntax or format 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?
Specific verb plus resource ('Casts a natal chart') followed by an enumeration of exactly what is returned: planet signs and degrees in two zodiacs, ascendant, twelve Placidus cusps, midheaven, retrograde state, Moon's nakshatra. This is clearly distinguishable from siblings such as get_planetary_positions (current positions) or compute_seven_governors_chart.
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 covers any chart, rising sign, Moon sign or planet-in-house' tells the agent what question types this tool answers, which is real usage guidance. It stops short of naming an alternative, e.g. when to reach for get_planetary_positions or compute_panchang instead, so there is no explicit exclusion or routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the four pillars (bazi) of a birth: the stem and branch of the year, month, day and hour, and each pair's place in the sixty cycle. Stems and branches only, no interpretation. Takes "date", "time" and "place".
The month changes at the solar terms, and the hour needs the birthplace's historic UTC offset. Without a birth time the call returns a time_required refusal.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date, ISO YYYY-MM-DD, Dec 1926-2100. Example: "1990-06-15". | |
| time | Yes | Birth time HH:MM, local at the birthplace. Example: "08:30". Required. | |
| place | Yes | Town or city of birth with region or country. Example: "Chicago, Illinois, US". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and closed-world, so the bar is lower, and the description still adds genuinely useful behavior: a time_required refusal when birth time is absent, solar-term month boundaries, dependence on the birthplace's historic UTC offset, and the presence of an attribution line plus permalink in the result. It does not describe result encoding or how an ambiguous place resolves, which keeps it off a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, then scope, inputs, edge cases and output in a sensible progression. The sentence 'Takes "date", "time" and "place"' largely repeats the schema's required list and is the one low-value line.
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 no output schema, the description does the work of stating what comes back (stems, branches, sixty-cycle positions, attribution, permalink) and what failure looks like (time_required). Remaining gaps — exact serialization and place-resolution ambiguity — are minor for a read-only calculation tool.
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 formats are already documented and the baseline is 3. The description earns a step up by explaining why place matters — it supplies the historic UTC offset needed for the hour pillar — and by reiterating that time is required, which carries behavioral weight beyond the schema's 'Required.'
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 (computes the four pillars/bazi of a birth) and enumerates the exact output: year/month/day/hour stems and branches plus each pair's position in the sixty cycle. The clause 'Stems and branches only, no interpretation' sharply delineates it from the interpretation-oriented chart siblings such as compute_birth_chart and compute_heluo_birth_hexagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'no interpretation' scope implies this is the raw-calculation step rather than a chart reading, and the required inputs are named. But no sibling is named and no explicit when-to-use/when-not condition is given, so the agent must infer the split from compute_birth_chart or convert_chinese_lunar_date.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the He Luo birth hexagram from "date", "time" and "place": the hexagram the He Luo Zhen Shu (preface dated 1591) counts from the four pillars, as the book reads a man's chart, a woman's, or both (read_as), with each rule's basis and locator. No interpretation.
Held-out test failed: 1 of 4 sealed book charts passed; 1 of 3 scored contradicts the stated rules. result.validation states this beside the hexagram.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date, ISO YYYY-MM-DD, Dec 1926-2100. Example: "1990-06-15". | |
| time | Yes | Birth time HH:MM, local at the birthplace. Example: "08:30". Required. | |
| place | Yes | Town or city of birth with region or country. Example: "Chicago, Illinois, US". | |
| read_as | No | Which of the book's readings; default "both". Example: "both". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely non-redundant behavior: no interpretation, each rule's basis and locator included, a held-out test failure reported in result.validation, plus an attribution line and permalink. The test-failure disclosure is unusually candid and materially informs the agent about output reliability.
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-loaded with the core action and scope, and every sentence carries information (source, no-interpretation boundary, validation failure, output extras). Slightly dense phrasing and the mid-paragraph test-failure note make it a touch harder to scan, but there is 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?
With no output schema, the description does the work of explaining what comes back: the hexagram, rule bases and locators, a validation verdict, attribution and a permalink. Given the tool's complexity and 4 fully documented params, this is close to complete; only the distinction from similarly-scoped sibling tools is left implicit.
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 defines date, time, place and the read_as enum. The description adds only marginal meaning (that read_as selects the book's male/female/both reading), which largely restates the enum's own description, so baseline 3 is appropriate.
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: computes the He Luo birth hexagram from date, time and place, citing the source text (He Luo Zhen Shu, preface 1591) and the read_as dimension, plus an explicit 'No interpretation' boundary. It is clear what it produces, though it does not explicitly contrast itself with compute_four_pillars or get_iching_hexagram_text, which an agent could plausibly confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the inputs and the read_as choice but gives no when-to-use guidance against the many astrology/divination siblings (e.g. compute_four_pillars, get_iching_hexagram_text). It notes the result carries a validation caveat but does not tell the agent when such a chart is the appropriate call versus an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts a Gregorian date to the Maya calendars: Tzolk'in day sign and tone as written (e.g. "6 Oc"), kin 1-260, the sign's meaning, direction and trecena, the Haab date, the Long Count and the Julian Day Number. It covers a Maya day sign or birth sign, or any event's Maya date.
The method is the Julian Day Number minus a correlation constant, then remainders mod 20, 13, 260 and 365, where an off-by-one gives a real day sign that is the wrong one. Which constant to use is the open argument in Maya calendrics: this uses Goodman-Martinez-Thompson 584283 and returns it. Time of day, place and zone play no part.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Gregorian date to convert, ISO YYYY-MM-DD, year 1-4000, proleptic before 1582. Example: "2012-12-21". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (read-only, idempotent, closed-world); the description goes well beyond them by disclosing the algorithm, the specific GMT correlation constant 584283 it returns, the off-by-one failure mode that produces a wrong day sign, and the presence of an attribution line and permalink in results. That is exactly the kind of assumption an agent needs to know before trusting or reusing the output.
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 first sentence front-loads the purpose and the full output list; the following paragraphs cover method and result metadata. The middle explanation of remainders and off-by-one is longer than strictly necessary to invoke the tool, but it is cohesive and each part is non-redundant, so the markup is minor.
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?
There is no output schema, and the description compensates fully by enumerating the returned components (Tzolk'in day sign/tone, kin, sign meaning, direction, trecena, Haab, Long Count, Julian Day Number) plus attribution and permalink. Combined with the stated correlation constant, an agent has everything needed to call it and interpret the result.
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 schema already specifies the ISO YYYY-MM-DD pattern, the year 1-4000 range, proleptic handling before 1582, and an example. The description only repeats 'Gregorian date' and adds no format or edge-case detail beyond the schema, so the baseline 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 ('Converts a Gregorian date to the Maya calendars') and then enumerates the exact outputs (Tzolk'in day sign and tone, kin, Haab, Long Count, JDN). This is clearly distinguishable from siblings like convert_calendar_date or convert_chinese_lunar_date without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the input domain ('a Maya day sign or birth sign, or any event's Maya date') and rules out irrelevant factors ('Time of day, place and zone play no part'), which is a genuine usage boundary. It does not name a sibling alternative for plain Gregorian calendar conversion, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the Moon's phase at an instant: phase angle, illuminated fraction, the eight-fold name, waxing or waning, age in days, tropical sign and degree, distance, and the four principal phases of that lunation to the second in UTC; optionally every principal phase across a date range.
A count of days from one new moon in steps of 29.53 follows the mean month, and a real new moon can fall more than half a day from the mean one; the gap is widest at the quarters and the full moon. Phase names follow Moon-Sun elongation. The phase changes within a day, so the hour matters; "time" is UTC and defaults to 00:00.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of a range, ISO YYYY-MM-DD, up to 400 days after date. Example: "2026-12-31". Lists every principal phase between. | |
| date | No | The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-20". Defaults to today (UTC). | |
| time | No | Time of day HH:MM, read as UTC. Example: "12:00". Defaults to 00:00 UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a safe, idempotent, non-destructive read, and the description adds substantive behavioral context: UTC handling, default time, within-day phase changes, mean-vs-real new moon caveats, and the inclusion of attribution and a permalink.
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 returned values and then adds caveats, so an agent can extract the purpose quickly. It is dense and slightly long, but most sentences earn their place by clarifying behavior or output.
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 no output schema, the description carries the return-value burden and does so thoroughly: it enumerates the phase metrics, principal phase times, optional range results, and even attribution/permalink. Safety behavior is covered by annotations, leaving no major gap for invocation.
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 date, time, and range behavior in detail. The description reinforces UTC/default behavior and the range's purpose, but does not add much parameter detail beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: returning the Moon's phase at an instant, with an explicit list of computed values and the lunation's principal phases. It is immediately distinguishable from siblings such as get_planetary_positions or find_eclipses.
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 clearly explains the default single-instant use and the optional date-range use for listing every principal phase. It does not explicitly name when to choose this over a sibling tool, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the panchang for one civil date at one place: tithi, nakshatra with pada, yoga and karana, each with the UTC and local instants it begins and ends, plus vara, sunrise, sunset, day length and the lunar month (amanta and purnimanta). Takes a place, or lat and lon.
A tithi is the interval in which the Moon gains twelve degrees on the Sun, 20-26.8 hours (mean 23.6), and the civil day it names is set by the tithi running at that place's sunrise, so two cities' panchangs for one date can differ by a whole tithi. Nakshatra about 20.8 to 27.2 hours, yoga about 19.5 to 25.2 hours, karana about 10 to 13.4 hours. A latitude with no sunrise that day is refused.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours, for printing local times only. Example: "Asia/Kolkata". | |
| lat | No | Latitude in decimal degrees as a string. Example: "28.6139". Paired with lon. | |
| lon | No | Longitude in decimal degrees as a string. Example: "77.209". It sets the sunrise the whole panchang is read at. | |
| date | No | Civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-20". Defaults to today (UTC). | |
| place | No | Town or city with region or country. Example: "Chennai, Tamil Nadu, India". Required unless lat and lon are given; an ambiguous name is refused with candidates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive, so the description correctly spends its words on behavior that annotations cannot express: two cities can differ by a whole tithi for the same date, ambiguous place names are refused with candidates, and a no-sunrise latitude is rejected. It also discloses that results carry an attribution line and a permalink, which is unusual and worth knowing, though it says nothing about response size or the date range limits that the schema only implies.
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-loaded with the verb, scope and output list; the second paragraph's orbital-period figures and sunrise rule genuinely earn their place by explaining result variability rather than padding. It is on the long side, and the interval durations for yoga and karana are the least load-bearing sentence, but nothing is redundant with structured fields.
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 no output schema, the description still tells the agent what comes back (each element with UTC and local begin/end instants, plus vara, sunrise, sunset, day length, both lunar-month systems, attribution and permalink). Combined with the refusal conditions and the sunrise rule, an agent has everything needed to call and interpret this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents place, lat, lon, tz and date with examples and the anyOf requirement. The description's 'takes a place, or lat and lon' restates that anyOf and adds no format, default or precedence detail beyond it, 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 verb (computes) and resource (the panchang) scoped to one civil date and one place, then enumerates the exact outputs (tithi, nakshatra with pada, yoga, karana, vara, sunrise/sunset, lunar month). This is clearly distinguishable from siblings like convert_calendar_date or get_solar_terms without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Takes a place, or lat and lon' names the two calling modes, and the description explains the sunrise-based day assignment so an agent understands why a place matters. It gives exclusion-like conditions (ambiguous name refused with candidates; a latitude with no sunrise is refused) but never names which sibling to prefer for adjacent needs such as solar terms or moon phase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the Chinese Seven Governors and Four Remainders chart from "date", "time" and "place": the life palace, and for the Sun, Moon, five planets, Luohou, Jidu, Yuebei and Ziqi the longitude in degrees, lodge, du and palace, plus home-palace and raised-to-hall dignities with page locators. Facts only: no reading or verdict.
The lodges are unequal in width and move with precession.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date, ISO YYYY-MM-DD, Dec 1926-2100. Example: "1990-06-15". | |
| time | Yes | Birth time HH:MM, local at the birthplace. Example: "08:30". Required. | |
| place | Yes | Town or city of birth with region or country. Example: "Chicago, Illinois, US". |
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 real context beyond that: lodge widths are unequal and precession-dependent, results carry an attribution line and permalink, and no interpretive verdict is returned.
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 core computation and output enumerations are front-loaded in the first sentence, with caveats and return notes following. Every sentence carries information, though the standalone note about unequal lodges reads as slightly detached.
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 no output schema, the description compensates by naming the returned fields (longitude, lodge, du, palace, dignities, page locators, attribution, permalink). For a deterministic read-only computation with 3 fully documented parameters, nothing essential 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%, with formats and examples already documented for all three parameters. The description only restates that date, time and place drive the computation, adding no format or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb ('Computes') on a precisely named resource ('Chinese Seven Governors and Four Remainders chart'), followed by an enumeration of the exact outputs produced. This clearly separates it from siblings like compute_birth_chart or compute_four_pillars, which cover different systems.
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?
Usage is implied by the required 'date'/'time'/'place' trio, and the 'Facts only: no reading or verdict' line sets expectation about scope. However, it never states when to choose this over compute_birth_chart or compute_four_pillars, leaving sibling routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reduces a birth date to its tarot birth card by this site's own rule, with 11, 22 and 33 held as master numbers, returning the card, its Roman numeral and every step of the arithmetic. It covers a birth, life or destiny card. The date alone decides it.
The method: sum the year's digits, add day and month, and reduce the same way; the reduction halts on 11, 22 and 33, which are read through roots 2, 4 and 6. 1993 sums to 22 and stops there; reducing on to 4 gives another card. Root 8 is Strength in the Rider-Waite-Smith numbering used here, and Justice in Marseille packs.
The rule is a twentieth-century convention found in no early tarot source.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date, ISO YYYY-MM-DD. Example: "1994-06-05" (reduces to 7, The Chariot). Time and place change nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, non-destructive, and closed-world. The description adds substantial behavioral context beyond that: the reduction halts on 11, 22, and 33, root 8 is Strength in Rider-Waite-Smith numbering, and results include an attribution line and permalink.
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 operation, then explains method, numbering, and outputs. It is mostly efficient, though the historical note about the rule being a twentieth-century convention is interesting but not necessary for invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so adequately by naming the card, Roman numeral, arithmetic steps, attribution line, and permalink. It also explains the reduction rule and the master-number behavior needed to understand edge cases.
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 schema already documents the date format, example, and the fact that time and place do not matter. The description reinforces that the date alone decides the result but adds little syntax or semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: reducing a birth date to a tarot birth card, including the returned card, Roman numeral, and arithmetic. It is clear what the tool computes, though it does not explicitly contrast itself with sibling birth computations such as compute_birth_chart or compute_heluo_birth_hexagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying it covers a birth, life, or destiny card and that the date alone decides it. However, it gives no explicit when-to-use guidance, no when-not conditions, and no routing to or away from related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes where the sky is on a chosen date against where it was at somebody's birth: ten transiting bodies with longitude, sign, degree, speed and retrograde state, and every aspect they make to the natal planets and angles, each with its orb, the orb allowed, the natal longitude measured against, and whether the contact is applying or separating. It covers what is transiting a chart, whether a transit is active on a date, a Saturn return, or whether a contact has perfected.
The computation takes two full sets of ecliptic longitudes (the birth instant, at the historic UTC offset of that place and date, and the target instant), then the angle between every pair taken the short way round the circle: about a hundred and fifty separations, each with a wrap case at 0 Aries. A contact is applying when its orb shrinks over the following hour, and separating when it grows.
The orb convention is in result.orbConvention. How close a transit has to be to count is a convention, and an aspect list without its orb cannot be checked. Here: 3 degrees for conjunction, opposition, trine and square, 2 for sextile, deliberately tighter than a natal chart's 8.
With "time" left out for an unknown birth time, the ascendant and midheaven are dropped entirely, because a transit to an angle cast for an arbitrary noon has no meaning. The Moon is included, where most software excludes it; the lunar nodes are excluded. Significance is interpretation and is not computed here.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Time of day for the transit, HH:MM, read as UTC. Example: "12:00". Defaults to 00:00 UTC. | |
| on | Yes | Date to read the sky for, ISO YYYY-MM-DD, 1700-2200. Example: today's date for "what is transiting me now". | |
| tz | No | IANA zone or numeric UTC offset hours for the birth moment. Example: "-5". When absent, resolved historically. | |
| lat | No | Birth latitude in decimal degrees as a string. Example: "39.76838". Paired with lon. | |
| lon | No | Birth longitude in decimal degrees as a string. Example: "-86.15804". Paired with lat. | |
| date | Yes | Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". The sky is read for the date in "on". | |
| time | No | Birth time HH:MM local at the birthplace. Example: "23:58". Optional; when it is absent the angles are dropped. | |
| place | Yes | Town or city of birth with region or country. Example: "Indianapolis, Indiana, United States". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds unusually valuable behavior that is not in the schema: the orb convention (3 degrees for conjunction, opposition, trine and square; 2 for sextile; tighter than natal), Moon included and nodes excluded, angles dropped when birth time is absent, and an attribution line plus permalink in results. It does not describe failure modes or invalid-input behavior, and the implementation detail about wrap cases adds bulk rather than actionable transparency; still, this is well above baseline.
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 first sentence leads with the output shape and scope, and each paragraph has a distinct job (returns, orb convention, special cases). A few sentences do not earn their place for an agent, notably the account of roughly 150 short-way separations with wrap cases at 0 Aries, which is implementation detail rather than invocation guidance.
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?
There is no output schema, so the description must describe return values, and it does so thoroughly: transiting bodies with longitude, sign, degree, speed and retrograde state; every aspect with orb, allowed orb, natal longitude and applying/separating state; plus orbConvention, attribution and a permalink. Edge cases (unknown birth time, Moon/nodes policy, date range stated in the schema) are covered, so 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%, so baseline is 3, and the schema itself documents each of the 8 parameters with examples and patterns. The description does add non-obvious meaning for `time`: when omitted, the ascendant and midheaven are dropped because transits to an angle cast for an arbitrary noon are meaningless; and it explains that the birth instant is resolved at the historic UTC offset of that place and date, which clarifies `tz`. It gives no guidance on `place` versus `lat`/`lon` precedence, so credit is limited.
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 verb and resource: it computes transiting bodies against a natal chart instant, and it enumerates the returned fields (longitude, sign, degree, speed, retrograde state, aspects with orbs and applying/separating state). That is clearly distinct from compute_birth_chart (natal positions) and get_planetary_positions (sky only, no chart comparison), so an agent can route correctly 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?
It names concrete use cases: "what is transiting a chart, whether a transit is active on a date, a Saturn return, or whether a contact has perfected." This gives clear context for when to call it, but it never explicitly names an alternative tool or states when not to use this one, such as using get_planetary_positions when no birth data is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the Vimshottari dasha timeline from a birth date, time and place: all nine mahadashas of the 120-year cycle, each with the exact instant it opens and closes, the balance at birth in years, months and days, the Moon's nakshatra and pada that fix the sequence, and the nine antardashas inside the mahadasha running on the "asof" date (the birth, when it is absent). The answer does not depend on the server clock, so it stays citable at a stable permalink.
The whole table hangs off one number, the Moon's sidereal longitude at the birth instant. The nakshatra it falls in names the first lord, and the share of that nakshatra still to be crossed, times the lord's years, is the balance at birth. A tenth of a degree moves the balance by weeks and every later boundary with it; a few degrees changes which planet the cycle opens with.
"time" is required here: the Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown birth time means an unknown first lord. Without it the call returns a "time_required" refusal. The cycle runs Ketu, Venus, Sun, Moon, Mars, Rahu, Jupiter, Saturn and Mercury, for 7, 20, 6, 10, 7, 18, 16, 19 and 17 years.
Three conventions come back in the result and are where two programs disagree about one chart: result.ayanamsa, result.yearLengthDays, result.origin.utcInstant. Against Drik Panchang every boundary here falls 1.70 days earlier; result.conventionNote explains the difference.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours for the birth moment. Example: "-5". When absent, resolved historically. | |
| lat | No | Birth latitude in decimal degrees as a string. Example: "39.76838". Paired with lon. | |
| lon | No | Birth longitude in decimal degrees as a string. Example: "-86.15804". Paired with lat. | |
| asof | No | Date to mark the active mahadasha and antardasha for. Example: today's date for "which dasha am I in now". | |
| date | Yes | Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". Other formats such as "19/10/1977" are refused. | |
| time | Yes | Birth time HH:MM, 24-hour, local at the birthplace. Example: "23:58". Required; without it the call returns time_required. | |
| place | Yes | Town or city of birth with region or country. Example: "Chennai, India". An ambiguous name is refused with candidates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, non-destructive, closed-world); the description goes far beyond by disclosing refusal behaviours ('time_required' without a birth time, ambiguous place refused with candidates), determinism independent of the server clock, a stable permalink, and the three convention fields plus a conventionNote explaining a 1.70-day offset versus Drik Panchang. That is exactly the kind of cross-implementation caveat an agent cannot get from structured fields.
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-loaded with the output inventory, then motivation, then caveats; each paragraph has a job. It is on the long side for a tool with full schema coverage, and the time-requirement point is made twice (in the prose and again in the schema description), which is mild redundancy rather than waste.
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 no output schema, the description carries the return-value burden and does so thoroughly: mahadasha/antardasha boundaries, balance at birth, nakshatra and pada, the convention fields, conventionNote, attribution line and permalink. Combined with the stated refusal modes, an agent has everything needed to call this correctly and interpret the result.
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 real meaning: why 'time' is mandatory (13.2°/day motion against a 13°20' nakshatra means an unknown time yields an unknown first lord) and that 'asof' defaults to the birth date when absent. It also names the three result fields (ayanamsa, yearLengthDays, origin.utcInstant) that drive divergence between programs, though it does not add anything for tz/lat/lon beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (computes the Vimshottari dasha timeline from birth data) and enumerates exactly what comes back: nine mahadashas of the 120-year cycle with opening/closing instants, balance at birth, Moon nakshatra/pada, and the nine antardashas for the asof date. This is clearly distinguishable from siblings like compute_birth_chart, compute_panchang or compute_transits, which produce different artefacts.
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?
Usage is implied through the parameters: use 'asof' for 'which dasha am I in now', and time is mandatory or the call refuses. But there is no explicit when-to-use/when-not guidance or routing against alternatives such as compute_panchang (which also touches nakshatra) or compute_birth_chart; the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts between the Gregorian and Julian calendars, the Julian Day Number and the three Maya counts (Tzolk'in, Haab, Long Count), any one to all the others, and searches a year range for a Calendar Round ("when was 4 Ahau 3 Kankin"). Takes exactly one starting point: a Gregorian date, a jdn, a longcount, a julian date, or a round with from and to. Two are refused.
Every conversion passes through the Julian Day Number, a single count of days. The Gregorian and Julian calendars drift apart by a different number of days each century (ten at the 1582 reform, thirteen now), and pre-reform dates are often quoted as Julian without saying so. A Calendar Round repeats every 18,980 days. States the Goodman-Martinez-Thompson constant 584283.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last Gregorian year of a Calendar Round search. Example: "2100". A wider span takes longer to search. | |
| jdn | No | Julian Day Number as a whole count of days. Example: "2456283". Not a fractional Julian Date. | |
| date | No | A proleptic Gregorian date, ISO YYYY-MM-DD. Example: "2012-12-21". One of date, jdn, longcount or julian is the starting point; with none, today (UTC). | |
| from | No | First Gregorian year of a Calendar Round search. Example: "1900". Only with round and to. | |
| round | No | Calendar Round to search: tone, day sign, haab day, haab month. Example: "4 Ahau 3 Kankin". Needs from and to. | |
| julian | No | A date in the Julian calendar, ISO YYYY-MM-DD. Example: "1582-10-04". For sources dated before October 1582. | |
| longcount | No | Maya Long Count, five dot-separated places baktun.katun.tun.uinal.kin. Example: "9.12.11.5.18". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides deep technical context beyond the standard annotations, explaining the methodology (passing through JDN), historical context (Julian vs. Gregorian drift by 10 vs. 13 days), and the specific cycle length of a Calendar Round (18,980 days). This is highly valuable domain knowledge.
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 highly dense, which is necessary given the complexity of the calendar systems it manages. It follows a logical progression from function definition to technical constraints, making the density justifiable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is exceptionally complete; it details the entire operational context—methodology, limitations, specific constant values, and expected output features (attribution line, permalink)—leaving virtually no ambiguity for the agent.
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?
While the schema coverage is 100%, the description adds vital semantic constraints that the schema cannot hold, such as stating that JDN must not be fractional, and providing a performance warning regarding wide searches for the 'to' and 'from' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the core function as conversion between specific, disparate calendar systems (Gregorian, Julian, Maya counts) and explicitly includes the complex feature of searching for a Calendar Round. This specificity distinguishes it from generic date 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 provides a critical constraint on input usage: 'Takes exactly one starting point,' and lists the types that are refused. This highly specific constraint prevents the agent from invoking the tool incorrectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts a Gregorian date to the Chinese lunisolar calendar or back: lunar year, month, day, whether the month is a leap month, when it began, and the solar term in effect. Takes "date" or "lunar", one of the two.
A month starts on the day, at Beijing time, of its new moon, so tables built in another zone can put months a day off. Placement follows GB/T 33661-2017. Leap months, 2033-2035 and pre-1929 dates come back unverified, with no date.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Gregorian date, ISO YYYY-MM-DD, 1929-3025. Example: "2024-02-10". Neither: today (UTC). | |
| leap | No | "yes" if the lunar date is in a leap month; only with lunar. Example: "yes". | |
| lunar | No | Lunar year-month-day, YYYY-MM-DD, year = Gregorian year of its month 1. Example: "2024-01-01". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: the Beijing-time new-moon rule for month boundaries, the GB/T 33661-2017 placement standard, explicit failure/uncertainty behavior (leap months, 2033-2035, pre-1929 come back unverified with no date), and the presence of an attribution line and permalink in the response. These are exactly the traits an agent cannot get from structured fields.
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?
Purpose is front-loaded in the first clause, and the caveat and output paragraphs are short. The second paragraph is compressed almost telegraphically ('Leap months, 2033-2035 and pre-1929 dates come back unverified, with no date'), which costs a little readability but wastes no words.
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?
There is no output schema, yet the description still enumerates the returned fields, the attribution/permalink, and the degradation cases where no date is returned. Combined with the dense boundary-rule note, an agent has everything needed to call this correctly and interpret the result.
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 earns above that by stating the mutual exclusivity of date/lunar ('one of the two'), a constraint the flat schema does not enforce or state. The leap-only-with-lunar rule is repeated from the schema but not expanded further.
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 names a specific verb and resource ('converts a Gregorian date to the Chinese lunisolar calendar or back') and enumerates exactly what the result contains (year, month, day, leap flag, month start, solar term). It does not explicitly distinguish itself from the sibling convert_calendar_date, so an agent scanning siblings still has to infer which converter handles which system.
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?
'Takes "date" or "lunar", one of the two' gives clear intra-tool selection guidance, and the 1929-3025 range is conveyed via the schema. But there is no statement of when to reach for this tool versus convert_calendar_date or get_solar_terms, and no exclusions; usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the solar and lunar eclipses nearest a date: greatest eclipse to the second in UTC, type, obscuration, the eclipsed body's sign, days from the date, and for a solar eclipse where greatest eclipse meets the Earth. Given a place, each listing also carries what that observer gets: local kind, first contact, maximum, last contact and altitude at each.
The 6,585.3-day saros groups eclipses into families whose members fall about a year or a continent apart, and a global eclipse is seen from only part of the Earth. Global and local circumstances are kept apart, including the Moon setting partway through or rising with the eclipse underway.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours for the local contact times. Example: "Atlantic/Reykjavik". | |
| lat | No | Observer latitude in decimal degrees as a string. Example: "64.1466". Paired with lon. | |
| lon | No | Observer longitude in decimal degrees as a string. Example: "-21.9426". Paired with lat. | |
| date | No | The date to search around, ISO YYYY-MM-DD, 1700-2200. Example: "2026-08-12". Defaults to today (UTC). | |
| count | No | How many per side of the date, "1" to "12", default "3". Example: "1". Each extra one adds server time. | |
| place | No | Observer town or city. Example: "Reykjavik, Iceland". Adds the local kind, contact times and altitudes. | |
| family | No | Which eclipses to list: "both" (the default), "lunar" or "solar". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met; the description adds real behavioral detail beyond that — results carry an attribution line and permalink, global and local circumstances are kept as separate sets, and edge cases like the Moon setting mid-eclipse are handled and disclosed. It does not state the output shape beyond field names, but it goes well past the annotation baseline.
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-loaded with the payload of results, which is the right priority. The opening sentence is long and comma-chained, and the saros paragraph is informative background rather than invocation-relevant, so a little trimming is possible.
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?
There is no output schema, and the description fully compensates by naming the returned fields (greatest eclipse in UTC to the second, type, obscuration, sign, days from date, local contacts and altitudes) plus the attribution and permalink. Nothing essential for correct invocation is missing for a 7-parameter, all-optional read tool.
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 earns above that by explaining what `place` and the lat/lon/tz trio actually unlock (local kind, first/maximum/last contact, altitude at each), which is the key semantic distinction an agent needs when deciding whether to pass coordinates. It does not elaborate on `count`, `family`, or `date` beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ("Finds the solar and lunar eclipses nearest a date") and immediately enumerates the returned fields, so the agent knows exactly what this produces. No sibling tool in the list (retrogrades, birth charts, moon phase) covers eclipses, so differentiation is achieved implicitly and unambiguously.
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?
Clear contextual guidance: supplying a place or lat/lon/tz adds observer-specific local circumstances, while omitting it yields global circumstances only. There is no explicit "when not to use" or named alternative, but no sibling overlaps this capability, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one of the 64 Zhouyi (I Ching) hexagrams by "hexagram" number: trigrams, lines, and the judgement text (and one line text if asked) as printed in an edition with a preface dated 1591, each column with its archive page locator. Text not confirmed against a second copy is withheld.
The English meaning is AI-written and labelled; no human scholar has checked it. Each quoted column carries its archive locator.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| line | No | A line, 1 (bottom) to 6 (top), to add its text. Example: "2". | |
| hexagram | Yes | Hexagram number in the received order, 1-64. Example: "11". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important provenance and reliability behavior: the edition has a preface dated 1591, each column carries an archive page locator, unconfirmed text is withheld, the English meaning is AI-written and unverified by a human scholar, and results include attribution and a permalink. These are substantive behavioral details that an agent would not know from the readOnly/idempotent annotations alone.
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 appropriately sized for a retrieval tool, but it repeats the archive locator point in two separate sentences. The information earns its place overall, though minor redundancy keeps it from being maximally concise.
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 no output schema, the description still explains what is returned: trigrams, lines, judgement text, optional line text, archive locators, attribution line, and permalink. It also covers key caveats about provenance and unverified translation, making the tool sufficiently complete for an agent to call and interpret results.
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 schema already documents both parameters, including examples for hexagram and line. The description reinforces that retrieval is by hexagram number and that a line text is added if requested, but it adds no real syntax or semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns one of the 64 Zhouyi/I Ching hexagrams by number, including trigrams, lines, judgement text, and optional line text. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as compute_heluo_birth_hexagram or other compute/retrieval 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?
Usage is implied by phrases like 'by hexagram number' and 'one line text if asked', but there is no explicit guidance on when to choose this tool versus related siblings. The description does not state exclusions or alternatives, leaving tool selection mostly to inference from the tool name and resource description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns where every body is at an instant, with no birth data and no place required: Sun, Moon, the eight planets and the two lunar nodes, each with geocentric ecliptic longitude, sign and degree in both the tropical (Western) and sidereal (Vedic) zodiacs, ecliptic latitude, longitude speed in degrees per day, retrograde state and distance. It covers "what sign is Venus in", "where is Mercury right now", "what sign is the Moon in today", "when did Mars enter Gemini": any position question about the sky with no particular person's chart in it.
A geocentric longitude is identical for every observer on Earth, so a sky question needs no birthplace and no chart. An observer's lat and lon are used only for rise and set times.
A planet sits within a degree of a cusp for days, so "Venus is in Scorpio" can be true on Tuesday and false on Wednesday; the Moon moves about half a degree an hour and changes sign roughly every 2.3 days, so its row depends on the hour as well as the date. "time" is UTC and defaults to 00:00.
Both zodiacs come back in every row: result.bodies[].sign is the tropical sign and result.bodies[].siderealSign the sidereal one. They differ by result.ayanamsa, about 24 degrees, very nearly a whole sign, so the two are usually different signs. Rahu and Ketu are the mean nodes (result.nodeNote). result.retrogradeNow lists which of the eight stationing bodies are retrograde; the two nodes, which move backwards every day, are reported apart in result.alwaysRetrograde.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours for the local rise and set times. Example: "Atlantic/Reykjavik". | |
| lat | No | Observer latitude in decimal degrees as a string. Example: "64.1466". Paired with lon. Rise and set only. | |
| lon | No | Observer longitude in decimal degrees as a string. Example: "-21.9426". Paired with lat. Rise and set only. | |
| date | No | The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-21". Defaults to today (UTC). | |
| time | No | Time of day HH:MM, read as UTC. Example: "12:00". Matters for the Moon, which moves about half a degree an hour. | |
| place | No | Observer town or city. Example: "Reykjavik, Iceland". Optional; it changes no position, only rise and set times. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description does not contradict them. It adds genuine context beyond annotations: time defaults to 00:00 UTC and is read as UTC, date defaults to today, mean nodes vs stationing bodies are reported in separate fields, and results carry an attribution line and permalink. The cusp/precision warnings (Venus sign flipping within days, Moon ~0.5 deg/hour) are unusually useful for interpreting results.
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?
Purpose and scope are front-loaded in the opening sentence, and the example phrasings and precision caveats each do real work. There is mild redundancy, though: the Moon's motion is invoked twice (sign change every ~2.3 days and half a degree an hour) across two paragraphs, and the attribution/permalink detail is minor for a description this long.
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 no output schema, the description carries the full burden of explaining returns, and it does: result.bodies[].sign vs siderealSign, result.ayanamsa, result.nodeNote, result.retrogradeNow vs result.alwaysRetrograde, plus attribution and permalink. All six params are characterized and the zero-required-parameter default behavior (date=today, time=00:00 UTC) is spelled out.
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, but the description adds meaning the schema does not: it explains why a sky question needs no birthplace and that lat/lon/place feed only rise/set. It also states the tropical/sidereal dual-return and the ~24 degree ayanamsa offset that makes the two signs usually differ, which affects how an agent reads results for a given date.
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 first sentence states a specific verb and resource and enumerates exactly what comes back: Sun, Moon, eight planets, two nodes, with longitude, sign, degree in both zodiacs, latitude, speed, retrograde state and distance. It explicitly contrasts itself with chart-based siblings ('no birth data and no place required'), so an agent can route between this and compute_birth_chart 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?
It names concrete triggering questions ('what sign is Venus in', 'where is Mercury right now', 'when did Mars enter Gemini') and gives an explicit exclusion boundary: 'any position question about the sky with no particular person's chart in it.' It also states that lat/lon/place affect rise-and-set times only, which tells the agent when those params are irrelevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the 24 solar terms of a "year" (1926-3026): the instant the Sun reaches each 15-degree mark of ecliptic longitude, in UTC, Beijing time and an optional zone, each with its uncertainty band in seconds.
A term's date depends on the clock it is read in, and fixed-date lists can be a day off either way. A year whose band touches a midnight comes back unverified, with no dates.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or UTC offset hours for local times. Example: "America/New_York". | |
| year | No | Gregorian year, YYYY, 1926-3026. Example: "2026". Defaults to this year (UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, non-destructive read, and the description adds substantial behavior beyond that: uncertainty bands in seconds, the unverified-year case where no dates are returned, and the presence of an attribution line and permalink in the response. The unverified edge case is exactly the kind of failure mode an agent needs to know before calling.
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 short, front-loaded paragraphs: what it returns, why the clock matters, and what comes back. Every sentence carries information, including the caveat about fixed-date lists, and nothing is padded. The stray quotes around "year" are the only blemish.
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?
There is no output schema, so the description has to describe the payload itself, and it does: the three time representations, the uncertainty band, the attribution line, the permalink, and the unverified case returning no dates. An agent has everything needed to decide to call it and to interpret the result.
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 both parameters are already documented with examples and the YYYY format. The description restates the year range and mentions the 'optional zone' but adds no format or interaction detail (e.g. offsets vs IANA names) beyond what the schema provides, so the baseline of 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 ('Returns the 24 solar terms of a year') and then defines exactly what a solar term is here: the instant the Sun reaches each 15-degree mark of ecliptic longitude. The year range (1926-3026) and the time bases (UTC, Beijing time, optional zone) pin the scope down so an agent can distinguish it from compute_panchang or convert_chinese_lunar_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second paragraph gives a real usage rationale: a term's date depends on the clock it is read in, and fixed-date lists can be a day off either way, which tells the agent to prefer this tool over static tables when precision matters. It does not, however, name any sibling alternative or say when not to use it, so it falls short of the explicit routing credit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves the UTC offset in force at a place on a date: the IANA zone that applied then, the signed offset, the UTC instant it resolves to, and a confidence of high, best-effort or low with the reason for anything below high. A statute that moved the zone is quoted with its Federal Register citation.
The present-day zone map can give the wrong offset for a past date. Tennessee was on Central time until 28 September 1947, so a Knoxville record from that March is UTC-6 where America/New_York gives UTC-5.
Results include an attribution line and a permalink.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The date wanted, ISO YYYY-MM-DD, 1800-2200. Example: "1947-03-15". | |
| time | No | Local clock time, 24-hour HH:MM. Example: "08:30". Defaults to midday. | |
| place | Yes | Town or city, with region or country. Example: "Knoxville, Tennessee, US". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety (readOnly, idempotent, closed-world); the description goes well beyond them, disclosing the returned fields, the three-tier confidence vocabulary and that low confidence comes with a reason, that governing statutes are quoted with Federal Register citations, and that output carries an attribution line and permalink. That is exactly the behavioral context annotations cannot convey.
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-loaded with the capability in the opening sentence and the motivation in the second. The output enumeration in the first sentence is list-heavy, and the attribution/permalink note is a minor tail, but nothing is redundant or padded.
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 no output schema, the description correctly takes on the return-value burden and explains confidence tiers and citations. Minor gaps remain: it does not say how ambiguous or unresolvable place names are handled, nor what the confidence applies to (the zone determination versus the offset), which matters given the tool's whole value proposition is reliability.
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 date range 1800-2200 and the midday default for time, so the baseline is 3. The description adds only indirect parameter meaning through the Knoxville example, which hints that 'place' must be granular enough for historic boundaries to matter, but it states no parameter rules itself.
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?
A specific verb ('resolves') plus a precisely scoped resource: the UTC offset in force at a place on a date, plus an enumeration of what comes back (IANA zone, signed offset, UTC instant, confidence, statute citation). No sibling tool does historic timezone resolution, so the boundary is unambiguous without reading any 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?
Strongly establishes when this tool is required over a generic present-day zone lookup, via the explicit Tennessee/Knoxville counter-example ('the present-day zone map can give the wrong offset for a past date'). It stops short of naming sibling alternatives such as convert_calendar_date or stating exclusions (e.g., future dates), so it is clear context rather than full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_retrogrades2 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". Omit: today (UTC)."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". Defaults to today (UTC)."Input schema / properties / time / descriptionPrevious value: -"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Matters within a day of a station."New value: +"Time of day HH:MM, read as UTC. Example: \"12:00\". Matters within a day of a station."compute_birth_chart5 fields changedInput schema / properties / date / descriptionPrevious value: -"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". Other formats such as \"19/10/1977\" are refused."Input schema / properties / lat / descriptionPrevious value: -"Latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."New value: +"Latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."Input schema / properties / lon / descriptionPrevious value: -"Longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."New value: +"Longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."Input schema / properties / time / descriptionPrevious value: -"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". Leave out if unknown; the ascendant and houses are then withheld."New value: +"Birth time HH:MM, 24-hour, local at the birthplace. Example: \"23:58\". Optional; when it is absent the ascendant and houses are withheld."Input schema / properties / tz / descriptionPrevious value: -"IANA zone or numeric UTC offset hours. Example: \"America/Indiana/Indianapolis\" or \"-5\". Omit: resolved for the BIRTH date."New value: +"IANA zone or numeric UTC offset hours. Example: \"America/Indiana/Indianapolis\" or \"-5\". When absent, resolved for the birth date."compute_moon_phase2 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Omit: today (UTC)."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Defaults to today (UTC)."Input schema / properties / time / descriptionPrevious value: -"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Omit for 00:00 UTC."New value: +"Time of day HH:MM, read as UTC. Example: \"12:00\". Defaults to 00:00 UTC."compute_panchang3 fields changedInput schema / properties / date / descriptionPrevious value: -"Civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Omit: today (UTC)."New value: +"Civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Defaults to today (UTC)."Input schema / properties / lat / descriptionPrevious value: -"Latitude in decimal degrees as a string. Example: \"28.6139\". Send with lon."New value: +"Latitude in decimal degrees as a string. Example: \"28.6139\". Paired with lon."Input schema / properties / place / descriptionPrevious value: -"Town or city with region or country. Example: \"Chennai, Tamil Nadu, India\". REQUIRED unless lat and lon are sent; an ambiguous name is refused with candidates."New value: +"Town or city with region or country. Example: \"Chennai, Tamil Nadu, India\". Required unless lat and lon are given; an ambiguous name is refused with candidates."compute_transits8 fields changedInput schema / properties / at / descriptionPrevious value: -"Time of day for the TRANSIT, HH:MM in UTC, not local and not the birth time. Example: \"12:00\". Omit for 00:00 UTC."New value: +"Time of day for the transit, HH:MM, read as UTC. Example: \"12:00\". Defaults to 00:00 UTC."Input schema / properties / date / descriptionPrevious value: -"BIRTH date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". The date to read the sky for is \"on\"."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". The sky is read for the date in \"on\"."Input schema / properties / lat / descriptionPrevious value: -"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."New value: +"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."Input schema / properties / lon / descriptionPrevious value: -"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."New value: +"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."Input schema / properties / on / descriptionPrevious value: -"Date to READ THE SKY FOR, ISO YYYY-MM-DD, 1700-2200. Example: today's date for \"what is transiting me now\"."New value: +"Date to read the sky for, ISO YYYY-MM-DD, 1700-2200. Example: today's date for \"what is transiting me now\"."Input schema / properties / place / descriptionPrevious value: -"Town or city of BIRTH with region or country. Example: \"Indianapolis, Indiana, United States\"."New value: +"Town or city of birth with region or country. Example: \"Indianapolis, Indiana, United States\"."Input schema / properties / time / descriptionPrevious value: -"BIRTH time HH:MM local at the birthplace. Example: \"23:58\". Leave out if unknown; the angles are then left out."New value: +"Birth time HH:MM local at the birthplace. Example: \"23:58\". Optional; when it is absent the angles are dropped."Input schema / properties / tz / descriptionPrevious value: -"IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."New value: +"IANA zone or numeric UTC offset hours for the birth moment. Example: \"-5\". When absent, resolved historically."compute_vimshottari_dasha5 fields changedInput schema / properties / date / descriptionPrevious value: -"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". Other formats such as \"19/10/1977\" are refused."Input schema / properties / lat / descriptionPrevious value: -"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."New value: +"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."Input schema / properties / lon / descriptionPrevious value: -"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."New value: +"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."Input schema / properties / time / descriptionPrevious value: -"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."New value: +"Birth time HH:MM, 24-hour, local at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."Input schema / properties / tz / descriptionPrevious value: -"IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."New value: +"IANA zone or numeric UTC offset hours for the birth moment. Example: \"-5\". When absent, resolved historically."convert_calendar_date3 fields changedInput schema / properties / date / descriptionPrevious value: -"A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". Send ONE of date, jdn, longcount, julian; none: today (UTC)."New value: +"A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". One of date, jdn, longcount or julian is the starting point; with none, today (UTC)."Input schema / properties / julian / descriptionPrevious value: -"A date in the JULIAN calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". For sources dated before October 1582."New value: +"A date in the Julian calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". For sources dated before October 1582."Input schema / properties / to / descriptionPrevious value: -"Last Gregorian year of a Calendar Round search. Example: \"2100\". A wider span is slower, not better."New value: +"Last Gregorian year of a Calendar Round search. Example: \"2100\". A wider span takes longer to search."find_eclipses4 fields changedInput schema / properties / count / descriptionPrevious value: -"How many per side of the date, \"1\" to \"12\", default \"3\". Example: \"1\". Ask for what you will use."New value: +"How many per side of the date, \"1\" to \"12\", default \"3\". Example: \"1\". Each extra one adds server time."Input schema / properties / date / descriptionPrevious value: -"The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Omit: today (UTC)."New value: +"The date to search around, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Defaults to today (UTC)."Input schema / properties / lat / descriptionPrevious value: -"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon."New value: +"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Paired with lon."Input schema / properties / lon / descriptionPrevious value: -"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat."New value: +"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Paired with lat."get_planetary_positions5 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\". Omit: today (UTC)."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\". Defaults to today (UTC)."Input schema / properties / lat / descriptionPrevious value: -"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon. Rise and set only."New value: +"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Paired with lon. Rise and set only."Input schema / properties / lon / descriptionPrevious value: -"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat. Rise and set only."New value: +"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Paired with lat. Rise and set only."Input schema / properties / place / descriptionPrevious value: -"Observer town or city. Example: \"Reykjavik, Iceland\". OPTIONAL: it changes no position, only rise and set times."New value: +"Observer town or city. Example: \"Reykjavik, Iceland\". Optional; it changes no position, only rise and set times."Input schema / properties / time / descriptionPrevious value: -"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Matters for the Moon, which moves about half a degree an hour."New value: +"Time of day HH:MM, read as UTC. Example: \"12:00\". Matters for the Moon, which moves about half a degree an hour."get_solar_terms1 field changedInput schema / properties / year / descriptionPrevious value: -"Gregorian year, YYYY, 1926-3026. Example: \"2026\". Omit: this year (UTC)."New value: +"Gregorian year, YYYY, 1926-3026. Example: \"2026\". Defaults to this year (UTC)."resolve_utc_offset1 field changedInput schema / properties / time / descriptionPrevious value: -"Local clock time, 24-hour HH:MM. Example: \"08:30\". Omit for midday."New value: +"Local clock time, 24-hour HH:MM. Example: \"08:30\". Defaults to midday."compute_birth_chart1 field changedInput schema / properties / time / descriptionPrevious value: -"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". OMIT if unknown; never send \"12:00\"."New value: +"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". Leave out if unknown; the ascendant and houses are then withheld."compute_transits1 field changedInput schema / properties / time / descriptionPrevious value: -"BIRTH time HH:MM local at the birthplace. Example: \"23:58\". OMIT if unknown; the angles are then left out."New value: +"BIRTH time HH:MM local at the birthplace. Example: \"23:58\". Leave out if unknown; the angles are then left out."compute_vimshottari_dasha1 field changedInput schema / properties / time / descriptionPrevious value: -"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". REQUIRED: never invent one, never send noon."New value: +"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."convert_calendar_date1 field changedInput schema / properties / julian / descriptionPrevious value: -"A date in the JULIAN calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". Use it for sources before October 1582."New value: +"A date in the JULIAN calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". For sources dated before October 1582."get_planetary_positions1 field changedInput schema / properties / time / descriptionPrevious value: -"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Send it for Moon questions."New value: +"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Matters for the Moon, which moves about half a degree an hour."check_retrogrades2 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". The stations returned bracket this date."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". Omit: today (UTC)."Input schema / requiredRemoved value: -[
- "date"
-]compute_moon_phase2 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Covers the lunation it falls inside."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Omit: today (UTC)."Input schema / requiredRemoved value: -[
- "date"
-]compute_panchang2 fields changedInput schema / properties / date / descriptionPrevious value: -"Local civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\"."New value: +"Civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Omit: today (UTC)."Input schema / requiredRemoved value: -[
- "date"
-]convert_calendar_date2 fields changedInput schema / anyOfRemoved value: -[
- {
- "required": [
- "date"
- ]
- },
- {
- "required": [
- "jdn"
- ]
- },
- {
- "required": [
- "longcount"
- ]
- },
- {
- "required": [
- "julian"
- ]
- },
- {
- "required": [
- "round",
- "from",
- "to"
- ]
- }
-]Input schema / properties / date / descriptionPrevious value: -"A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". Send exactly ONE of date, jdn, longcount, julian."New value: +"A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". Send ONE of date, jdn, longcount, julian; none: today (UTC)."convert_chinese_lunar_date2 fields changedInput schema / anyOfRemoved value: -[
- {
- "required": [
- "date"
- ]
- },
- {
- "required": [
- "lunar"
- ]
- }
-]Input schema / properties / date / descriptionPrevious value: -"Gregorian date, ISO YYYY-MM-DD, 1929-3025. Example: \"2024-02-10\"."New value: +"Gregorian date, ISO YYYY-MM-DD, 1929-3025. Example: \"2024-02-10\". Neither: today (UTC)."find_eclipses2 fields changedInput schema / properties / date / descriptionPrevious value: -"The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Need not be an eclipse date."New value: +"The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Omit: today (UTC)."Input schema / requiredRemoved value: -[
- "date"
-]get_planetary_positions2 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\", or today's for \"where is Mercury right now\"."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\". Omit: today (UTC)."Input schema / requiredRemoved value: -[
- "date"
-]get_solar_terms2 fields changedInput schema / properties / year / descriptionPrevious value: -"Gregorian year, YYYY, 1926-3026. Example: \"2026\"."New value: +"Gregorian year, YYYY, 1926-3026. Example: \"2026\". Omit: this year (UTC)."Input schema / requiredRemoved value: -[
- "year"
-]compute_heluo_birth_hexagramcompute_seven_governors_chartcompute_four_pillarsconvert_chinese_lunar_dateget_iching_hexagram_textget_solar_termsresolve_utc_offsetcheck_retrogrades3 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, zero-padded, between 1700 and 2200. Examples: \"2026-03-01\", today's date for \"is Mercury retrograde right now\". The stations returned bracket the period this date falls inside."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-03-01\". The stations returned bracket this date."Input schema / properties / time / descriptionPrevious value: -"Time of day as HH:MM in UTC — not a local time and not a birth time. Example: \"12:00\". Omit it for 00:00 UTC. It only changes the answer within about a day of a station, which is exactly when somebody is likely to be asking."New value: +"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Matters within a day of a station."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "bodies": {
- "items": {
- "properties": {
- "currentPeriodEnd": {
- "description": "The station that closes it. Same shape, same null rule.",
- "type": "object"
- },
- "currentPeriodStart": {
- "description": "The station that OPENED the period this body is currently in — its type, its exact UTC instant, and the degree it stationed at. null when no station falls inside the search window, which the page says rather than leaving blank. This field and the next are the reason to call this endpoint instead of reading a speed.",
- "type": "object"
- },
- "formattedDegree": {
- "description": "Degree within the sign, for display.",
- "type": "string"
- },
- "longitudeSpeedPerDay": {
- "description": "Degrees of ecliptic longitude per day. Negative while retrograde; near zero at a station.",
- "type": "number"
- },
- "planet": {
- "description": "One of the eight bodies that can station.",
- "type": "string"
- },
- "retrograde": {
- "description": "Apparent motion at that instant.",
- "type": "boolean"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "date": {
- "description": "The date asked about.",
- "type": "string"
- },
- "directNow": {
- "description": "The bodies moving direct at that instant.",
- "type": "array"
- },
- "excluded": {
- "items": {
- "properties": {
- "bodies": {
- "description": "What is deliberately not in the list: the Sun and Moon, which cannot station, and Rahu and Ketu, which move backwards every day of their existence.",
- "type": "array"
- },
- "reason": {
- "description": "Why, in full. Quote it if the user asks about any of those four rather than reporting an absence.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "instantUTC": {
- "description": "The instant the speeds were read at. It matters within about a day of a station.",
- "type": "string"
- },
- "retrogradeNow": {
- "description": "The names only, for a caller that wants the one-line answer. Empty when nothing is retrograde, which is itself the answer.",
- "type": "array"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_birth_chart7 fields changedInput schema / properties / date / descriptionPrevious value: -"Birth date, ISO YYYY-MM-DD, between 1800-01-01 and 2200-12-31. Zero-padded. Example: \"1977-10-19\". \"1977-10-9\" and \"19/10/1977\" are refused rather than interpreted, because guessing which half is the month is how a chart silently becomes a different chart."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."Input schema / properties / lat / descriptionPrevious value: -"Latitude in decimal degrees, −90 to 90, as a string. Example: \"39.76838\". Only for a caller who already holds exact coordinates; must be sent together with lon. Half a coordinate pair is refused, never completed from the place name."New value: +"Latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."Input schema / properties / lon / descriptionPrevious value: -"Longitude in decimal degrees, −180 to 180, as a string. Example: \"-86.15804\". Must be sent together with lat."New value: +"Longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."Input schema / properties / place / descriptionPrevious value: -"Town or city of birth, with the region and country when the name is a common one. Examples: \"Indianapolis, Indiana, United States\", \"Reykjavík, Iceland\", \"Varanasi, Uttar Pradesh, India\". A bare \"Springfield\" or \"Cambridge\" is refused with a list of the candidate places rather than resolved to one, because they sit in different time zones and would produce different charts. Not needed if lat and lon are given."New value: +"Town or city of birth with region and country. Example: \"Indianapolis, Indiana, United States\". A bare \"Springfield\" is refused with candidates."Input schema / properties / time / descriptionPrevious value: -"Birth time as HH:MM on a 24-hour clock, in LOCAL time at the birthplace — not UTC. Example: \"23:58\" for two minutes to midnight, \"09:07\" for morning. OMIT THIS FIELD ENTIRELY if the birth time is unknown. Do not send \"12:00\", \"00:00\" or any invented value: the result would carry an ascendant and twelve houses that are a guess, and nothing downstream would mark them as one. Omitted, the answer returns the planetary positions and states plainly that it is withholding the ascendant and the houses."New value: +"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". OMIT if unknown; never send \"12:00\"."Input schema / properties / tz / descriptionPrevious value: -"IANA zone name, or a plain numeric UTC offset in hours. Examples: \"America/Indiana/Indianapolis\", \"-5\", \"5.75\" for Nepal. Leave it out and the zone is resolved for the BIRTH DATE — including historic reassignments — which is almost always what you want. Send it only when the user has told you the offset and it disagrees with the map."New value: +"IANA zone or numeric UTC offset hours. Example: \"America/Indiana/Indianapolis\" or \"-5\". Omit: resolved for the BIRTH date."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "omittedBodyNote": {
- "description": "A sentence when a body we normally place is missing because our source for it does not reach this date. Chiron is the only such body: it comes from a JPL Horizons table covering 1920-01-01 to 2060-01-06, while this calculator accepts 1800 to 2200. Quote it rather than letting a reader conclude the body was placed and was unremarkable.",
- "type": "object"
- },
- "origin": {
- "properties": {
- "clockChangeNote": {
- "description": "A sentence when this wall-clock time occurred twice, or never occurred, because clocks changed that day. Says which of the two instants was used and how far the ascendant moves if the other was meant. Quote it with the offset.",
- "type": "object"
- },
- "dstRuleNote": {
- "description": "A sentence when a pre-1967 United States summer offset is inherited from the town the zone is named after rather than recorded for the birthplace. Names that town and the standard-time alternative. Quote it with the offset.",
- "type": "object"
- },
- "historicNote": {
- "description": "A sentence when a historic zone reassignment was applied, null when none was. Worth surfacing: it is the difference between a right and a wrong ascendant.",
- "type": "object"
- },
- "latitude": {
- "description": "The resolved latitude, never a default.",
- "type": "number"
- },
- "localMeanTimeNote": {
- "description": "A sentence when standard time had not yet reached this place, so the offset is mean time computed from the birthplace's own meridian. Names the longitude used and how far it is from the one the time zone database would have used. Quote it with the offset.",
- "type": "object"
- },
- "longitude": {
- "description": "The resolved longitude.",
- "type": "number"
- },
- "offsetLabel": {
- "description": "That zone's offset at that instant, written out.",
- "type": "string"
- },
- "timezone": {
- "description": "The IANA zone resolved for the birth DATE, not for today.",
- "type": "string"
- },
- "utcInstant": {
- "description": "The instant the chart was cast for, in UTC. Everything else follows from it.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "timeKnown": {
- "description": "false when no birth time was given. The ascendant and houses are then absent rather than guessed.",
- "type": "boolean"
- },
- "vedic": {
- "properties": {
- "nakshatra": {
- "description": "The lunar mansion the Moon occupied AT THE BIRTH INSTANT. A point-in-time fact with no interval attached, which is what makes it different from the panchang tool's nakshatra: that one is the mansion running over a stretch of a given day and carries the instants it begins and ends. A birth chart has no validity window, so this field has no boundaries and should not be quoted as though it did.",
- "type": "string"
- },
- "planets": {
- "items": {
- "properties": {
- "sign": {
- "description": "The same instant read against the sidereal zodiac, Lahiri ayanamsa.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "western": {
- "properties": {
- "ascendantFormatted": {
- "description": "The ascendant in degrees and minutes. Absent when the birth time is unknown.",
- "type": "string"
- },
- "houseSystem": {
- "description": "Which house system produced the cusps. Placidus below about 66.06 degrees of latitude, Porphyry at or above it, where Placidus is undefined. Null when the birth time is unknown. Quote this rather than assuming Placidus.",
- "type": "string"
- },
- "houses": {
- "description": "Twelve house cusps, in the system named by result.western.houseSystem. Empty when the birth time is unknown.",
- "type": "array"
- },
- "moonSign": {
- "description": "Tropical moon sign.",
- "type": "string"
- },
- "planets": {
- "items": {
- "properties": {
- "formattedDegree": {
- "description": "Degree within the sign, for display.",
- "type": "string"
- },
- "longitude": {
- "description": "Ecliptic longitude in degrees, 0 to 360 — the figure to compute with.",
- "type": "number"
- },
- "name": {
- "description": "The body.",
- "type": "string"
- },
- "retrograde": {
- "description": "Apparent motion at that instant.",
- "type": "boolean"
- },
- "sign": {
- "description": "Its sign.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "sunSign": {
- "description": "Tropical sun sign.",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_maya_day_sign2 fields changedInput schema / properties / date / descriptionPrevious value: -"The Gregorian date to convert, ISO YYYY-MM-DD, between year 1 and year 4000. Zero-padded, and proleptic Gregorian before 1582. Examples: \"2012-12-21\" (the end of the thirteenth baktun), \"1994-06-05\", \"0790-03-14\". A birth date, today, or a date in the ninth century all work the same way."New value: +"Gregorian date to convert, ISO YYYY-MM-DD, year 1-4000, proleptic before 1582. Example: \"2012-12-21\"."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "daySign": {
- "properties": {
- "name": {
- "description": "The day sign in the conventional spelling.",
- "type": "string"
- },
- "reformedSpelling": {
- "description": "The same sign in the reformed Guatemalan orthography.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "haab": {
- "properties": {
- "written": {
- "description": "The Haab date, e.g. \"3 Kankin\".",
- "type": "string"
- }
- },
- "type": "object"
- },
- "julianDayNumber": {
- "description": "The Julian Day Number the conversion went through, so the arithmetic can be checked against any other implementation.",
- "type": "number"
- },
- "kin": {
- "description": "Position in the 260-day Tzolk'in round, 1 to 260.",
- "type": "number"
- },
- "longCount": {
- "description": "The Long Count on the GMT correlation constant 584283.",
- "type": "string"
- },
- "tone": {
- "description": "The tone, 1 to 13.",
- "type": "number"
- },
- "tzolkinDate": {
- "description": "Tone and sign together, e.g. \"4 Ahau\".",
- "type": "string"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_moon_phase4 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, zero-padded, between 1700 and 2200. Example: \"2026-09-20\". The answer covers the lunation this date falls inside, so the surrounding new, quarter and full moons come back with it."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\". Covers the lunation it falls inside."Input schema / properties / time / descriptionPrevious value: -"Time of day as HH:MM in UTC — not a local time and not a birth time. Example: \"12:00\". Omit it for 00:00 UTC. Send it when the user cares which side of a phase boundary their hour falls on; convert their local time to UTC first rather than passing a local clock reading through."New value: +"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Omit for 00:00 UTC."Input schema / properties / to / descriptionPrevious value: -"End of a date range, ISO YYYY-MM-DD, up to 400 days after date. Example: \"2026-12-31\". Send it to get every principal phase between the two dates — this is the parameter for \"list the full moons in 2026\"."New value: +"End of a range, ISO YYYY-MM-DD, up to 400 days after date. Example: \"2026-12-31\". Lists every principal phase between."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "illuminatedFraction": {
- "description": "Fraction of the disc lit, 0 to 1. The real one for this instant, not an eighth-of-a-cycle approximation.",
- "type": "number"
- },
- "instantUTC": {
- "description": "The instant the phase was computed for, in UTC. The phase moves measurably within a day, so this is not decoration.",
- "type": "string"
- },
- "lunation": {
- "items": {
- "properties": {
- "daysFromQuery": {
- "description": "Days from the instant asked about. Negative for a phase already past.",
- "type": "number"
- },
- "phase": {
- "description": "One of the four principal phases bracketing this instant: New Moon, First Quarter, Full Moon, Last Quarter.",
- "type": "string"
- },
- "utc": {
- "description": "The exact instant of that phase, to the second, found by search rather than interpolation.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "moon": {
- "properties": {
- "distanceKm": {
- "description": "Geocentric distance in kilometres. The Moon is not always the same size.",
- "type": "number"
- },
- "formattedDegree": {
- "description": "Its degree within that sign, for display.",
- "type": "string"
- },
- "sign": {
- "description": "The Moon's tropical sign.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "moonAgeDays": {
- "description": "Days since the new moon that opened this lunation. Computed from the real new moon, not from a mean synodic month, which varies by up to thirteen hours either side.",
- "type": "number"
- },
- "nextFullMoonUTC": {
- "description": "The next full moon after this instant.",
- "type": "string"
- },
- "nextNewMoonUTC": {
- "description": "The next new moon after this instant.",
- "type": "string"
- },
- "phaseAngle": {
- "description": "Elongation of the Moon from the Sun in degrees: 0 at new, 90 at first quarter, 180 at full, 270 at last quarter.",
- "type": "number"
- },
- "phaseName": {
- "description": "The eight-fold name a reader expects, e.g. \"Waxing Gibbous\".",
- "type": "string"
- },
- "range": {
- "description": "null unless a `to` date was given. When present it carries from, to and every principal phase between them.",
- "type": "object"
- },
- "waxing": {
- "description": "True while the illuminated fraction is growing.",
- "type": "boolean"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_panchang6 fields changedInput schema / properties / date / descriptionPrevious value: -"The civil date, ISO YYYY-MM-DD, zero-padded, between 1700 and 2200. Example: \"2026-09-20\". This is the local civil day at the place given, which is what a printed panchang is organised by."New value: +"Local civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-20\"."Input schema / properties / lat / descriptionPrevious value: -"Latitude in decimal degrees, −90 to 90, as a string. Example: \"28.6139\". Only for a caller who already holds exact coordinates; must be sent together with lon, and half a pair is refused rather than completed from a name."New value: +"Latitude in decimal degrees as a string. Example: \"28.6139\". Send with lon."Input schema / properties / lon / descriptionPrevious value: -"Longitude in decimal degrees, −180 to 180, as a string. Example: \"77.209\". Must be sent together with lat. Longitude is the one that moves the answer: it sets the sunrise the whole panchang is read at."New value: +"Longitude in decimal degrees as a string. Example: \"77.209\". It sets the sunrise the whole panchang is read at."Input schema / properties / place / descriptionPrevious value: -"Town or city, with the region or country when the name is a common one. Examples: \"New Delhi, India\", \"Chennai, Tamil Nadu, India\", \"Leicester, England\". REQUIRED unless lat and lon are sent. An ambiguous name is refused with the candidates listed — relay them and ask which, because two places at different longitudes have different sunrises and therefore different tithis."New value: +"Town or city with region or country. Example: \"Chennai, Tamil Nadu, India\". REQUIRED unless lat and lon are sent; an ambiguous name is refused with candidates."Input schema / properties / tz / descriptionPrevious value: -"IANA zone name, or a plain numeric UTC offset in hours, used only for printing the local clock times. Examples: \"Asia/Kolkata\", \"5.5\". Leave it out and the zone is resolved for that place on that date."New value: +"IANA zone or numeric UTC offset hours, for printing local times only. Example: \"Asia/Kolkata\"."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "ayanamsa": {
- "description": "The ayanamsa the sidereal longitudes were taken on.",
- "type": "string"
- },
- "date": {
- "description": "The civil date the limbs were read for, at the place given.",
- "type": "string"
- },
- "dayLengthHours": {
- "description": "Hours between sunrise and sunset.",
- "type": "number"
- },
- "karana": {
- "properties": {
- "endLocal": {
- "description": "When it ends, carrying its date and its UTC offset. A karana is half a tithi, so it runs about 10 to 13.4 hours and two of them end within most civil days.",
- "type": "string"
- },
- "endUTC": {
- "description": "The same end boundary as a UTC instant to the second.",
- "type": "string"
- },
- "lengthHours": {
- "description": "How long this karana runs, in hours. Always about half the tithi it sits in, and every second karana ends exactly where its tithi does.",
- "type": "number"
- },
- "name": {
- "description": "The karana, the half-tithi.",
- "type": "string"
- },
- "startLocal": {
- "description": "When this karana began, on the local clock, carrying its date and its UTC offset. The date is on it because a karana boundary can fall on a different civil day from the date you asked about.",
- "type": "string"
- },
- "startUTC": {
- "description": "The same start boundary as a UTC instant to the second.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "masa": {
- "properties": {
- "adhika": {
- "description": "True in an intercalary month.",
- "type": "boolean"
- },
- "amanta": {
- "description": "The lunar month on the new-moon-to-new-moon reckoning used across southern and western India.",
- "type": "string"
- },
- "purnimanta": {
- "description": "The same month on the full-moon-to-full-moon reckoning used across the north. The two names differ for half of every month, which is why both are returned rather than one being chosen.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "nakshatra": {
- "properties": {
- "endLocal": {
- "description": "When it ends, carrying its date and its UTC offset. A nakshatra runs about 20.8 to 27.2 hours, the longest of the four, so its span contains a local midnight 97 per cent of the time — more often than any other limb — and this boundary frequently falls on the day AFTER the date asked about. For New Delhi on 2026-09-20 it is 2026-09-21. Quote the date with the time.",
- "type": "string"
- },
- "endUTC": {
- "description": "The same end boundary as a UTC instant to the second.",
- "type": "string"
- },
- "lengthHours": {
- "description": "How long this nakshatra runs, in hours — about 20.8 to 27.2 hours, averaging 24.3. Never a flat 24, because the Moon's speed varies through its orbit.",
- "type": "number"
- },
- "name": {
- "description": "The Moon's nakshatra at sunrise.",
- "type": "string"
- },
- "pada": {
- "description": "Which quarter of the nakshatra, 1 to 4.",
- "type": "number"
- },
- "startLocal": {
- "description": "When this nakshatra began, on the local clock, carrying its date and its UTC offset — \"2026-09-20 01:42 UTC+5:30\". The date is on it because a nakshatra boundary can fall on a different civil day from the date you asked about.",
- "type": "string"
- },
- "startUTC": {
- "description": "The same start boundary as a UTC instant to the second.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "place": {
- "properties": {
- "label": {
- "description": "The place as it was resolved. Compare it with what you sent: a panchang is a question about a place, and the wrong place is a different day's answer.",
- "type": "string"
- },
- "latitude": {
- "description": "The resolved latitude.",
- "type": "number"
- },
- "longitude": {
- "description": "The resolved longitude. This is the one that moves the answer — it sets the sunrise the whole reading hangs on.",
- "type": "number"
- },
- "timezone": {
- "description": "The IANA zone resolved for that place on that date, used only for the local clock times.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "sunriseLocal": {
- "description": "The same instant on the clock at that place, which is how a printed panchang gives it.",
- "type": "string"
- },
- "sunriseUTC": {
- "description": "The instant the day's limbs are read at. Everything below is true AT THIS MOMENT, which is the classical rule rather than a convenience.",
- "type": "string"
- },
- "sunsetLocal": {
- "description": "Sunset on the local clock.",
- "type": "string"
- },
- "tithi": {
- "properties": {
- "endLocal": {
- "description": "When it ends, carrying its date and its UTC offset. A tithi is not a day: it runs about 20 to 26.8 hours, averaging 23.6 and ends at an arbitrary clock time, which is the whole reason the sunrise rule exists — and why this boundary frequently falls on the following day.",
- "type": "string"
- },
- "endUTC": {
- "description": "The same end boundary as a UTC instant to the second.",
- "type": "string"
- },
- "lengthHours": {
- "description": "Its actual length in hours.",
- "type": "number"
- },
- "name": {
- "description": "The lunar day running at sunrise.",
- "type": "string"
- },
- "paksha": {
- "description": "Shukla (waxing) or Krishna (waning).",
- "type": "string"
- },
- "startLocal": {
- "description": "When this tithi began, on the local clock, carrying its date and its UTC offset — \"2026-09-20 17:51 UTC+5:30\". A tithi boundary crosses midnight routinely, so a bare clock time would be ambiguous by a full day.",
- "type": "string"
- },
- "startUTC": {
- "description": "The same start boundary as a UTC instant to the second.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "vara": {
- "properties": {
- "name": {
- "description": "The weekday, counted from sunrise rather than from midnight.",
- "type": "string"
- },
- "sanskrit": {
- "description": "Its Sanskrit name, e.g. Ravivara.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "yoga": {
- "properties": {
- "endLocal": {
- "description": "When it ends, carrying its date and its UTC offset. The summed longitudes move faster than any other panchang quantity, so a yoga is the shortest of the four spans at about 19.5 to 25.2 hours. Its boundary still lands on a different civil day from its start 93.4 per cent of the time, because a span only has to be long enough to reach a midnight.",
- "type": "string"
- },
- "endUTC": {
- "description": "The same end boundary as a UTC instant to the second.",
- "type": "string"
- },
- "lengthHours": {
- "description": "How long this yoga runs, in hours.",
- "type": "number"
- },
- "name": {
- "description": "The yoga, from the summed sidereal longitudes of Sun and Moon.",
- "type": "string"
- },
- "startLocal": {
- "description": "When this yoga began, on the local clock, carrying its date and its UTC offset. The date is on it because a yoga boundary can fall on a different civil day from the date you asked about.",
- "type": "string"
- },
- "startUTC": {
- "description": "The same start boundary as a UTC instant to the second.",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_tarot_birth_card2 fields changedInput schema / properties / date / descriptionPrevious value: -"Birth date, ISO YYYY-MM-DD, zero-padded. Examples: \"1994-06-05\" (reduces to 7, The Chariot), \"1993-11-02\" (a year that halts on the master number 22). The calendar date is the whole input; a birth time changes nothing here."New value: +"Birth date, ISO YYYY-MM-DD. Example: \"1994-06-05\" (reduces to 7, The Chariot). Time and place change nothing."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "card": {
- "description": "The tarot birth card.",
- "type": "string"
- },
- "compound": {
- "description": "The compound number before the final reduction.",
- "type": "number"
- },
- "numeral": {
- "description": "Its Roman numeral in the Rider-Waite-Smith trumps.",
- "type": "string"
- },
- "reduced": {
- "description": "The reduced destiny number.",
- "type": "number"
- },
- "root": {
- "description": "The root the card is taken from.",
- "type": "number"
- },
- "steps": {
- "items": {
- "properties": {
- "label": {
- "description": "What this line of the arithmetic does.",
- "type": "string"
- },
- "working": {
- "description": "The arithmetic itself, so the answer can be checked by hand.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_transits9 fields changedInput schema / properties / at / descriptionPrevious value: -"Time of day for the TRANSIT, HH:MM in UTC — not a local time and not the birth time. Example: \"12:00\". Omit it for 00:00 UTC. It matters most for the Moon, whose contacts last about eleven hours."New value: +"Time of day for the TRANSIT, HH:MM in UTC, not local and not the birth time. Example: \"12:00\". Omit for 00:00 UTC."Input schema / properties / date / descriptionPrevious value: -"BIRTH date, ISO YYYY-MM-DD, between 1800-01-01 and 2200-12-31. Example: \"1977-10-19\". This is the natal half; the date to read the sky for is \"on\"."New value: +"BIRTH date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". The date to read the sky for is \"on\"."Input schema / properties / lat / descriptionPrevious value: -"Birth latitude in decimal degrees as a string, e.g. \"39.76838\". Must be sent together with lon."New value: +"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."Input schema / properties / lon / descriptionPrevious value: -"Birth longitude in decimal degrees as a string, e.g. \"-86.15804\". Must be sent together with lat."New value: +"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."Input schema / properties / on / descriptionPrevious value: -"The date to READ THE SKY FOR, ISO YYYY-MM-DD, between 1700 and 2200. REQUIRED. Send today's date for \"what is transiting my chart now\"; send a past date for \"what was transiting when X happened\". There is no default: the birth date would return every planet conjunct its own natal position, which is the chart compared with itself, and \"today\" is not a default this server will assume because the result is published at a permalink."New value: +"Date to READ THE SKY FOR, ISO YYYY-MM-DD, 1700-2200. Example: today's date for \"what is transiting me now\"."Input schema / properties / place / descriptionPrevious value: -"Town or city of BIRTH, with the region or country when the name is a common one. Example: \"Indianapolis, Indiana, United States\"."New value: +"Town or city of BIRTH with region or country. Example: \"Indianapolis, Indiana, United States\"."Input schema / properties / time / descriptionPrevious value: -"BIRTH time, HH:MM on a 24-hour clock, local at the birthplace. Example: \"23:58\". Optional — OMIT IT if the user does not know it rather than filling it in. Without it the ascendant and midheaven are left out of the natal points entirely rather than cast for an arbitrary noon."New value: +"BIRTH time HH:MM local at the birthplace. Example: \"23:58\". OMIT if unknown; the angles are then left out."Input schema / properties / tz / descriptionPrevious value: -"IANA zone name or a numeric UTC offset in hours for the BIRTH moment, e.g. \"-5\". Leave it out and the zone is resolved for the birth date, historic reassignments included."New value: +"IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "aspectCount": {
- "description": "How many contacts are within orb. Zero is a real answer, not a failure.",
- "type": "number"
- },
- "aspects": {
- "items": {
- "properties": {
- "allowedOrb": {
- "description": "The width this aspect was allowed under the published convention, so a row can be checked against the table without cross-referencing.",
- "type": "number"
- },
- "applying": {
- "description": "true while the orb is still closing — the contact has not perfected. false once it has and is widening. Measured by re-reading the orb an hour later, which is correct for a retrograde body and for a pair straddling 0° Aries without a special case.",
- "type": "boolean"
- },
- "aspect": {
- "description": "Conjunction, Sextile, Square, Trine or Opposition. Major aspects only — those are the five TRANSIT_ORBS declares a width for.",
- "type": "string"
- },
- "natal": {
- "description": "The natal point contacted: a planet, or Ascendant or Midheaven when a birth time was given.",
- "type": "string"
- },
- "natalLongitude": {
- "description": "The natal longitude the aspect was measured against, so the row can be checked by hand.",
- "type": "number"
- },
- "orb": {
- "description": "Degrees off exact. Zero would be a perfect hit.",
- "type": "number"
- },
- "transiting": {
- "description": "The moving body.",
- "type": "string"
- },
- "transitingSpeedPerDay": {
- "description": "Degrees of longitude per day for the moving body, so a caller can see how long the contact has left. Negative while retrograde.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "emptyNote": {
- "description": "Said out loud when the list is empty, because an empty array reads like a failure. Null otherwise.",
- "type": "object"
- },
- "natal": {
- "properties": {
- "duplicatePointNote": {
- "description": "Non-null when the natal points contain two names for one physical point, which they do whenever the chart carries both the mean lunar nodes (North Node, South Node) and the True Node. They sit up to about 1°40' apart, so the same contact frequently appears twice under two names. Both are listed because the birth chart itself publishes both and dropping one here would make the two pages disagree about which points a chart has. Surface this rather than letting a reader count one contact as two.",
- "type": "string"
- },
- "points": {
- "description": "Every natal longitude the grid was measured against, so the answer can be checked without casting the chart again. Identical to what /api/public/birth-chart returns for the same inputs.",
- "type": "array"
- },
- "timeKnown": {
- "description": "false when no birth time was given. The ascendant and midheaven are then absent from natal.points entirely — not defaulted — because both sweep the whole zodiac in a day and a noon-cast angle is arbitrary rather than approximate.",
- "type": "boolean"
- },
- "timeUnknownNote": {
- "description": "The sentence explaining that absence, non-null exactly when timeKnown is false. Surface it: a reader who cannot see why the angles are missing will assume they were not aspected.",
- "type": "object"
- }
- },
- "type": "object"
- },
- "orbConvention": {
- "properties": {
- "natalComparison": {
- "description": "What the natal profile would have given instead, so a caller can see the size of the choice.",
- "type": "string"
- },
- "note": {
- "description": "Why these widths and not the natal ones, in a sentence.",
- "type": "string"
- },
- "table": {
- "description": "THE ORBS, in the payload. There is no fact of the matter about how close a transit has to be before it counts and practitioners differ by a lot, so an aspect grid without its orb is a list of opinions presented as measurements. Reproduce this wherever you reproduce the aspects.",
- "type": "object"
- }
- },
- "type": "object"
- },
- "positions": {
- "items": {
- "properties": {
- "body": {
- "description": "One of the ten transiting bodies. The Moon IS included — it moves about 13.2° a day so its contacts last about eleven hours, which is why a forecast drops it and why an instant answer should not. The lunar nodes are not included.",
- "type": "string"
- },
- "speedPerDay": {
- "description": "Degrees of ecliptic longitude per day. Negative means retrograde; that is the definition.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "tightest": {
- "description": "The closest contact, or null when nothing is within orb. Tightest is arithmetic; which contact MATTERS is an opinion and is not computed here.",
- "type": "object"
- },
- "transit": {
- "properties": {
- "instantUTC": {
- "description": "The instant the sky was read at, UTC to the second. It comes from the REQUIRED `on` parameter: there is no default, because the birth date would return every planet conjunct its own natal position and \"today\" would make the permalink answer differently tomorrow.",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullcompute_vimshottari_dasha8 fields changedInput schema / properties / asof / descriptionPrevious value: -"The date to mark the active mahadasha and antardasha for, ISO YYYY-MM-DD. SEND TODAY'S DATE for \"which dasha am I in now\" — this tool never reads the clock itself, so without this it answers about the period running at birth. Send a past date to ask which period was running then."New value: +"Date to mark the active mahadasha and antardasha for. Example: today's date for \"which dasha am I in now\"."Input schema / properties / date / descriptionPrevious value: -"Birth date, ISO YYYY-MM-DD, zero-padded, between 1800-01-01 and 2200-12-31. Example: \"1977-10-19\". \"19/10/1977\" is refused rather than interpreted, because guessing which half is the month produces a different timeline."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."Input schema / properties / lat / descriptionPrevious value: -"Birth latitude in decimal degrees as a string, for example \"39.76838\". Must be sent together with lon, and is an alternative to place rather than an addition to it."New value: +"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."Input schema / properties / lon / descriptionPrevious value: -"Birth longitude in decimal degrees as a string, for example \"-86.15804\". Must be sent together with lat."New value: +"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."Input schema / properties / place / descriptionPrevious value: -"Town or city of birth, with the region or country when the name is a common one. Examples: \"Indianapolis, Indiana, United States\", \"Chennai, India\". It is needed for the birthplace's historic UTC offset, which fixes the birth instant the whole cycle is measured from."New value: +"Town or city of birth with region or country. Example: \"Chennai, India\". An ambiguous name is refused with candidates."Input schema / properties / time / descriptionPrevious value: -"Birth time, HH:MM on a 24-hour clock, LOCAL AT THE BIRTHPLACE. Example: \"23:58\". REQUIRED — do not invent one and do not send noon. The Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown time is an unknown first lord and a timeline moved by years. If the user does not know it, ask; do not substitute."New value: +"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". REQUIRED: never invent one, never send noon."Input schema / properties / tz / descriptionPrevious value: -"IANA zone name, or a numeric UTC offset in hours, for the BIRTH moment. Examples: \"America/Indiana/Indianapolis\", \"-5\". Leave it out and the zone is resolved for the birth date, historic reassignments included — which is usually more accurate than anything you would supply."New value: +"IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "activeAntardasha": {
- "description": "The antardasha containing asOf. Null only when asOf sits exactly on the cycle end.",
- "type": "object"
- },
- "activeMahadasha": {
- "properties": {
- "antardashas": {
- "description": "The nine sub-periods of the active mahadasha, same shape as a mahadasha plus mahaLord. Each is the mahadasha's length times that sub-lord's share of 120, so the nine sum exactly to the period containing them.",
- "type": "array"
- }
- },
- "type": "object"
- },
- "asOf": {
- "description": "The date the active period was selected for. NEVER the wall clock: it is the asof parameter, defaulting to the birth date, so the permalink returns the same answer to anyone who opens it.",
- "type": "string"
- },
- "asOfDefaultedToBirth": {
- "description": "true when asof was not sent. Send today's date to ask which period is running now.",
- "type": "boolean"
- },
- "ayanamsa": {
- "properties": {
- "degrees": {
- "description": "The ayanamsa at the birth instant, in degrees.",
- "type": "number"
- },
- "name": {
- "description": "The sidereal frame the Moon was read in: Lahiri (Chitrapaksha). A dasha table computed on a different ayanamsa is a different table.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "balanceAtBirth": {
- "properties": {
- "lord": {
- "description": "The lord of the period already running at birth.",
- "type": "string"
- },
- "remainingText": {
- "description": "The balance in years, months and days — the figure every printed dasha table leads with and the one a reader checks first. Months and days here are twelfths and 365.25ths of a Vimshottari year, not calendar units.",
- "type": "string"
- },
- "remainingYears": {
- "description": "The same balance as a decimal count of Vimshottari years.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "conventionNote": {
- "description": "WHY ANOTHER PROGRAM'S TABLE MAY DIFFER, named so the difference can be accounted for rather than argued about. One convention decides it now that the year length agrees with the published implementations: the exact Lahiri variant. A sub-arcminute difference in the Moon becomes days once multiplied through a mahadasha. Measured against Drik Panchang for one birth, every boundary here falls 1.70 days earlier — the same 1.70 at the first and the ninth, because no second term survives. Quote this rather than asserting either table is correct; the two best-known published sources differ from each other by 1.04 days on that same birth.",
- "type": "string"
- },
- "cycleEndsUTC": {
- "description": "When the 120-year cycle from this birth closes. An asof beyond it is refused rather than clamped to the last period.",
- "type": "string"
- },
- "mahadashas": {
- "items": {
- "properties": {
- "active": {
- "description": "Whether the asOf instant falls inside this period. Exactly one row is true.",
- "type": "boolean"
- },
- "durationYears": {
- "description": "Length in Vimshottari years. The first is short by the balance; the other eight are the lord's full period.",
- "type": "number"
- },
- "endLocal": {
- "description": "The same, for the close.",
- "type": "string"
- },
- "endUTC": {
- "description": "The exact instant it closes, which is the instant the next one opens.",
- "type": "string"
- },
- "lord": {
- "description": "One of the nine Vimshottari lords, in the fixed sequence from the first.",
- "type": "string"
- },
- "startLocal": {
- "description": "The same instant on the birthplace's clock, carrying its own date and UTC offset — because a bare clock reading is ambiguous by a full day.",
- "type": "string"
- },
- "startUTC": {
- "description": "The exact instant the period opens, UTC to the second. Not a date: a dasha boundary falls at a clock time and crosses midnight as often as not.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "moon": {
- "properties": {
- "fractionElapsed": {
- "description": "How far through the nakshatra the Moon had travelled, 0 to 1. This is the fraction of the first period already spent before birth.",
- "type": "number"
- },
- "nakshatra": {
- "description": "The nakshatra that longitude falls in, which names the lord of the first mahadasha.",
- "type": "string"
- },
- "pada": {
- "description": "The quarter of the nakshatra, 1 to 4.",
- "type": "number"
- },
- "siderealLongitude": {
- "description": "The Moon's sidereal longitude at birth. The single number the whole timeline hangs off.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "origin": {
- "properties": {
- "historicNote": {
- "description": "A sentence when a historic zone reassignment was applied, null when none was. It is the difference between a right and a wrong balance.",
- "type": "object"
- },
- "offsetLabel": {
- "description": "The birthplace's UTC offset on the birth date, written out.",
- "type": "string"
- },
- "utcInstant": {
- "description": "The birth instant in UTC. Every date in the timeline is measured from it.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "yearLengthDays": {
- "description": "The length of a Vimshottari year in days. The classical text gives the periods and the order and never states one, so this is a CONVENTION: it is the true sidereal year, which is what Drik Panchang requests from its own API and what Jagannatha Hora defaults to. Software stepping a different year — the Julian 365.25, for instance — disagrees by an amount that grows across the cycle, about 0.76 days by the far end for that one.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullconvert_calendar_date8 fields changedInput schema / properties / date / descriptionPrevious value: -"A proleptic Gregorian date, ISO YYYY-MM-DD, zero-padded. Examples: \"2012-12-21\", \"0790-03-14\". Send this OR jdn OR longcount OR julian — exactly one. Sending two is refused rather than answered from whichever the server happens to read first."New value: +"A proleptic Gregorian date, ISO YYYY-MM-DD. Example: \"2012-12-21\". Send exactly ONE of date, jdn, longcount, julian."Input schema / properties / from / descriptionPrevious value: -"First Gregorian year of a Calendar Round search, as a whole number, for example \"1900\". Only meaningful together with round and to."New value: +"First Gregorian year of a Calendar Round search. Example: \"1900\". Only with round and to."Input schema / properties / jdn / descriptionPrevious value: -"A Julian Day Number as a whole count of days, for example \"2456283\". Not a fractional Julian Date: a fraction names an instant, and this converter answers about calendar days."New value: +"Julian Day Number as a whole count of days. Example: \"2456283\". Not a fractional Julian Date."Input schema / properties / julian / descriptionPrevious value: -"A date in the JULIAN calendar, ISO YYYY-MM-DD, for example \"1582-10-04\" — the day before the Gregorian reform. Use this whenever a source predates October 1582, because such a source is almost certainly Julian-dated whether or not it says so."New value: +"A date in the JULIAN calendar, ISO YYYY-MM-DD. Example: \"1582-10-04\". Use it for sources before October 1582."Input schema / properties / longcount / descriptionPrevious value: -"A Maya Long Count, five dot-separated places largest first — baktun.katun.tun.uinal.kin. Examples: \"9.12.11.5.18\", \"13.0.0.0.0\". This is the direction worth calling for: give a Long Count and the Gregorian date comes back."New value: +"Maya Long Count, five dot-separated places baktun.katun.tun.uinal.kin. Example: \"9.12.11.5.18\"."Input schema / properties / round / descriptionPrevious value: -"A Maya Calendar Round to search for, written as tone, day sign, haab day, haab month. Examples: \"4 Ahau 3 Kankin\" (colonial spelling), \"4 Ajaw 3 K'ank'in\" (reformed). Requires from and to. A Calendar Round repeats every 52 years, so without a year range the answer would be infinite."New value: +"Calendar Round to search: tone, day sign, haab day, haab month. Example: \"4 Ahau 3 Kankin\". Needs from and to."Input schema / properties / to / descriptionPrevious value: -"Last Gregorian year of a Calendar Round search, for example \"2100\". Ask for the span you actually want: a wider one is not more accurate, only slower."New value: +"Last Gregorian year of a Calendar Round search. Example: \"2100\". A wider span is slower, not better."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "calendarDivergenceDays": {
- "description": "How many days the Julian calendar has fallen behind the Gregorian one on this day: ten at the 1582 reform, thirteen through the twentieth and twenty-first centuries. The number a pre-reform source is usually out by.",
- "type": "number"
- },
- "correlationConstant": {
- "description": "584283, the Goodman–Martinez–Thompson constant. Returned with every answer because there is no such thing as \"the\" Maya date for a Gregorian date without naming one.",
- "type": "number"
- },
- "gregorian": {
- "properties": {
- "iso": {
- "description": "The proleptic Gregorian date, YYYY-MM-DD.",
- "type": "string"
- },
- "weekday": {
- "description": "The day of the week, computed from the day count rather than from a Date object.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "inputKind": {
- "description": "Which of the four starting points the request used: gregorian, julian-day-number, long-count or julian-calendar. Echoed so you can tell that the converter read your input the way you meant it.",
- "type": "string"
- },
- "inputValue": {
- "description": "That input as it was understood, normalised.",
- "type": "string"
- },
- "julianCalendar": {
- "properties": {
- "iso": {
- "description": "The same day in the Julian calendar. Not the same string as the Gregorian one for any date since 300 CE — the two calendars agreed exactly through the third century.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "julianDayNumber": {
- "description": "The Julian Day Number every conversion goes through. This is the figure to check against another implementation, because everything else is derived from it.",
- "type": "number"
- },
- "maya": {
- "properties": {
- "calendarRound": {
- "description": "The Tzolk'in and Haab pair, which repeats every 18,980 days. This is what the round search looks for.",
- "type": "string"
- },
- "daysSinceEpoch": {
- "description": "Days elapsed since the correlation epoch. Negative before it.",
- "type": "number"
- },
- "haab": {
- "description": "The Haab date, e.g. \"3 Kankin\".",
- "type": "string"
- },
- "longCount": {
- "description": "The Long Count in baktun.katun.tun.uinal.kin form.",
- "type": "string"
- },
- "tzolkin": {
- "description": "Tone and day sign together, e.g. \"4 Ahau\".",
- "type": "string"
- }
- },
- "type": "object"
- },
- "roundSearch": {
- "description": "null unless a Calendar Round search was asked for. When present it carries the query, the year range, a matches array and a truncated flag.",
- "type": "object"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullfind_eclipses8 fields changedInput schema / properties / count / descriptionPrevious value: -"How many eclipses to list on EACH side of the date, \"1\" to \"12\". Default is \"3\". Example: \"1\" for the single nearest one in each direction. Ask for what you will use."New value: +"How many per side of the date, \"1\" to \"12\", default \"3\". Example: \"1\". Ask for what you will use."Input schema / properties / date / descriptionPrevious value: -"The date to search AROUND, ISO YYYY-MM-DD, between 1700 and 2200. Examples: \"2026-08-12\", \"1999-08-11\". It does not have to be a date an eclipse falls on — today's date answers \"when is the next one\"."New value: +"The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-08-12\". Need not be an eclipse date."Input schema / properties / family / descriptionPrevious value: -"Which eclipses to list: \"both\" (the default), \"lunar\", or \"solar\". Narrow it when the user asked about one kind; a lunar eclipse and a solar eclipse near the same date are different events and listing both invites them to be conflated."New value: +"Which eclipses to list: \"both\" (the default), \"lunar\" or \"solar\"."Input schema / properties / lat / descriptionPrevious value: -"Observer latitude in decimal degrees as a string, for example \"64.1466\". Must be sent together with lon, and is an alternative to place rather than an addition to it."New value: +"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon."Input schema / properties / lon / descriptionPrevious value: -"Observer longitude in decimal degrees as a string, for example \"-21.9426\". Must be sent together with lat."New value: +"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat."Input schema / properties / place / descriptionPrevious value: -"Town or city of the observer. Examples: \"Reykjavik, Iceland\", \"Chennai, India\". Send it when the user asked whether THEY would see it, and every listing gains local kind, local clock times and the body's altitude at each contact. Omit it when they asked what is happening in the sky, because the global answer is the true one there."New value: +"Observer town or city. Example: \"Reykjavik, Iceland\". Adds the local kind, contact times and altitudes."Input schema / properties / tz / descriptionPrevious value: -"IANA zone name or a numeric UTC offset in hours, used for the local contact times. Examples: \"Atlantic/Reykjavik\", \"0\". Leave it out and the zone is resolved for the place given."New value: +"IANA zone or numeric UTC offset hours for the local contact times. Example: \"Atlantic/Reykjavik\"."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "date": {
- "description": "The date searched around, not a date an eclipse falls on.",
- "type": "string"
- },
- "family": {
- "description": "both, lunar or solar — what was actually listed.",
- "type": "string"
- },
- "nearest": {
- "description": "The eclipse nearest the date in either direction, so a caller wanting one answer does not have to compare two arrays. null only when the search found nothing at all.",
- "type": "object"
- },
- "place": {
- "description": "null when no place was given. When present, every listing also carries a `local` block, and only then does the answer say anything about what somebody would SEE.",
- "type": "object"
- },
- "previous": {
- "items": {
- "properties": {
- "kind": {
- "description": "total, annular, partial, penumbral, or hybrid.",
- "type": "string"
- },
- "peakUTC": {
- "description": "Greatest eclipse, to the second in UTC, for an eclipse before the date.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "upcoming": {
- "items": {
- "properties": {
- "daysFromQuery": {
- "description": "Days from the date asked about.",
- "type": "number"
- },
- "greatestAt": {
- "description": "Where greatest eclipse touches the Earth, as latitude and longitude. Solar only; null for a lunar eclipse.",
- "type": "object"
- },
- "label": {
- "description": "A readable name for the event, e.g. \"total solar eclipse\".",
- "type": "string"
- },
- "local": {
- "description": "null unless a place was given. When present: the local kind, which can be weaker than the global one, the local clock times of first contact, maximum and last contact, and the altitude of the body at each — because \"the Moon sets partway through\" and \"it is already underway at moonrise\" are different sentences and only one of them is actionable.",
- "type": "object"
- },
- "nakedEye": {
- "description": "Whether there is something a person could actually see. A penumbral lunar eclipse is a real event and very nearly nothing to look at.",
- "type": "boolean"
- },
- "obscuration": {
- "description": "Fraction of the disc covered at greatest eclipse, 0 to 1. Null for a partial SOLAR eclipse, where the quantity is not defined without an observer — give a place and read local.obscuration instead.",
- "type": "number"
- },
- "peakUTC": {
- "description": "The same for an eclipse after the date.",
- "type": "string"
- },
- "sign": {
- "description": "The zodiac sign of the eclipsed body — the Moon for lunar, the Sun for solar.",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullget_planetary_positions7 fields changedInput schema / properties / date / descriptionPrevious value: -"The date, ISO YYYY-MM-DD, zero-padded, between 1700 and 2200. Examples: \"2026-09-21\", today's date for \"where is Mercury right now\"."New value: +"The date, ISO YYYY-MM-DD, 1700-2200. Example: \"2026-09-21\", or today's for \"where is Mercury right now\"."Input schema / properties / lat / descriptionPrevious value: -"Observer latitude in decimal degrees as a string, e.g. \"64.1466\". Must be sent together with lon. Only affects rise and set."New value: +"Observer latitude in decimal degrees as a string. Example: \"64.1466\". Send with lon. Rise and set only."Input schema / properties / lon / descriptionPrevious value: -"Observer longitude in decimal degrees as a string, e.g. \"-21.9426\". Must be sent together with lat. Only affects rise and set."New value: +"Observer longitude in decimal degrees as a string. Example: \"-21.9426\". Send with lat. Rise and set only."Input schema / properties / place / descriptionPrevious value: -"Town or city of an observer. OPTIONAL, and it changes NOTHING about any longitude, sign, degree or speed — those are geocentric and identical everywhere on Earth. It adds rise and set times for each body. Send it only when the user asked when something is visible; omit it for every question about what sign a planet is in."New value: +"Observer town or city. Example: \"Reykjavik, Iceland\". OPTIONAL: it changes no position, only rise and set times."Input schema / properties / time / descriptionPrevious value: -"Time of day as HH:MM in UTC — not a local time and not a birth time. Example: \"12:00\". Omit it for 00:00 UTC. Send it whenever the question involves the Moon, which moves about half a degree an hour, or a body the user says is near a sign boundary; convert their local time to UTC first rather than passing a local clock reading through."New value: +"Time of day HH:MM in UTC, not local and not a birth time. Example: \"12:00\". Send it for Moon questions."Input schema / properties / tz / descriptionPrevious value: -"IANA zone name or a numeric UTC offset in hours, for the local rise and set times. Examples: \"Atlantic/Reykjavik\", \"0\"."New value: +"IANA zone or numeric UTC offset hours for the local rise and set times. Example: \"Atlantic/Reykjavik\"."Output schema / (root)Previous value: -{
- "$defs": {
- "Citation": {
- "description": "How to credit this answer. Present on every response, successes and refusals alike.",
- "properties": {
- "aiTrainingNote": {
- "type": "string"
- },
- "aiTrainingPermitted": {
- "const": false,
- "type": "boolean"
- },
- "attributionRequired": {
- "const": true,
- "type": "boolean"
- },
- "citationFormat": {
- "type": "string"
- },
- "citationMarkdown": {
- "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
- "type": "string"
- },
- "citationText": {
- "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
- "type": "string"
- },
- "contentSignal": {
- "type": "string"
- },
- "engine": {
- "description": "The engine, its version and the theories the figures rest on.",
- "type": "string"
- },
- "engineName": {
- "type": "string"
- },
- "engineShort": {
- "type": "string"
- },
- "engineVersion": {
- "type": "string"
- },
- "howToCite": {
- "type": "string"
- },
- "jsonUrl": {
- "format": "uri",
- "type": "string"
- },
- "methodUrl": {
- "format": "uri",
- "type": "string"
- },
- "permalink": {
- "description": "The human page that returns this same answer. This is the URL to link.",
- "format": "uri",
- "type": "string"
- },
- "publisher": {
- "type": "string"
- },
- "sourceName": {
- "type": "string"
- },
- "sourceUrl": {
- "format": "uri",
- "type": "string"
- },
- "termsUrl": {
- "format": "uri",
- "type": "string"
- },
- "theories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "usageTerms": {
- "type": "string"
- }
- },
- "required": [
- "attributionRequired",
- "citationText",
- "permalink",
- "engine",
- "termsUrl"
- ],
- "type": "object"
- }
- },
- "properties": {
- "attribution": {
- "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
- "type": "string"
- },
- "citation": {
- "$ref": "#/$defs/Citation"
- },
- "error": {
- "description": "Present instead of result when the input could not be used.",
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "suggestions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "inputs": {
- "description": "What the request was understood to be. The permalink is built from these.",
- "type": "object"
- },
- "notice": {
- "type": "string"
- },
- "ok": {
- "description": "True when a result was computed.",
- "type": "boolean"
- },
- "result": {
- "description": "The computed figures. Absent on a refusal.",
- "properties": {
- "ayanamsa": {
- "properties": {
- "degrees": {
- "description": "The angle between the two zodiac columns at this instant, in degrees.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "bodies": {
- "items": {
- "properties": {
- "body": {
- "description": "One of twelve: the Sun, the Moon, the eight planets, and Rahu and Ketu.",
- "type": "string"
- },
- "distanceAU": {
- "description": "Distance from the Earth in astronomical units — the Moon's too, so the units never change between rows.",
- "type": "number"
- },
- "formattedDegree": {
- "description": "Degree and arcminute within the sign, the way a chart sheet prints it.",
- "type": "string"
- },
- "latitude": {
- "description": "Ecliptic latitude in degrees. Zero by construction for the two nodes.",
- "type": "number"
- },
- "longitude": {
- "description": "Apparent geocentric ecliptic longitude in the TROPICAL zodiac, degrees. Geocentric means as seen from the centre of the Earth — identical for every observer on the planet, which is why no place is required.",
- "type": "number"
- },
- "retrograde": {
- "description": "Apparent motion at this instant. For the full period a body is inside, with its bracketing stations, use /api/public/retrogrades.",
- "type": "boolean"
- },
- "rise": {
- "description": "Rise at the place given, as a UTC instant and a local stamp carrying its own date and offset. null when no place was given, and null for a body that genuinely does not rise at that latitude on that date, which is a real configuration and not a gap.",
- "type": "object"
- },
- "set": {
- "description": "The same for setting.",
- "type": "object"
- },
- "siderealLongitude": {
- "description": "The same longitude with the Lahiri (Chitrapaksha) ayanamsa subtracted. Not a second observation — the same sky measured from a different zero point.",
- "type": "number"
- },
- "siderealSign": {
- "description": "The sidereal sign, which is what a Vedic reader means by the question. It differs from the tropical sign for most bodies most of the time.",
- "type": "string"
- },
- "sign": {
- "description": "The tropical sign. This is the answer to \"what sign is Venus in\" as a Western reader means it.",
- "type": "string"
- },
- "speedPerDay": {
- "description": "Degrees of ecliptic longitude per day, as a 24-hour centred difference. Negative means retrograde; that is the definition, not a separate fact.",
- "type": "number"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "instantUTC": {
- "description": "The instant every figure below was read at, UTC to the second.",
- "type": "string"
- },
- "nodeNote": {
- "description": "Rahu and Ketu here are the MEAN nodes. The true node oscillates around them by up to about 1°40', enough to sit on the other side of a sign boundary, so software configured for the true node will disagree near a cusp. Quote this rather than letting a reader assume.",
- "type": "string"
- },
- "place": {
- "description": "The observer, when one was given, with a `changes` field stating exactly what having it altered: rise and set, and nothing else. null when no place was sent.",
- "type": "object"
- },
- "placeNote": {
- "description": "Said whether or not a place was given, because the absence is the point: a geocentric longitude does not need one, and demanding a birthplace to produce one would be demanding a number that is never used.",
- "type": "string"
- },
- "retrogradeNow": {
- "description": "The names only, for a caller that wants the one-line answer. Empty when nothing is retrograde, which is itself the answer.",
- "type": "array"
- }
- },
- "type": "object"
- },
- "summary": {
- "description": "The answer in one sentence.",
- "type": "string"
- },
- "tool": {
- "description": "The calculator that answered.",
- "type": "string"
- },
- "toolName": {
- "type": "string"
- }
- },
- "required": [
- "ok",
- "tool",
- "attribution",
- "citation"
- ],
- "type": "object"
-}New value: +nullconvert_calendar_date1 field changedOutput schema / properties / result / properties / julianCalendar / properties / iso / descriptionPrevious value: -"The same day in the Julian calendar. Not the same string as the Gregorian one for any date since 200 CE."New value: +"The same day in the Julian calendar. Not the same string as the Gregorian one for any date since 300 CE — the two calendars agreed exactly through the third century."compute_vimshottari_dasha2 fields changedOutput schema / properties / result / properties / conventionNote / descriptionPrevious value: -"WHY ANOTHER PROGRAM'S TABLE MAY DIFFER, named so the difference can be accounted for rather than argued about. Two conventions decide these dates: the exact Lahiri implementation (a sub-arcminute difference in the Moon becomes days once multiplied through a mahadasha) and the Vimshottari year length. Measured against Drik Panchang for one birth, every boundary here falls 3.10 to 3.84 days earlier, and that decomposes entirely into those two terms. Quote this rather than asserting either table is correct."New value: +"WHY ANOTHER PROGRAM'S TABLE MAY DIFFER, named so the difference can be accounted for rather than argued about. One convention decides it now that the year length agrees with the published implementations: the exact Lahiri variant. A sub-arcminute difference in the Moon becomes days once multiplied through a mahadasha. Measured against Drik Panchang for one birth, every boundary here falls 1.70 days earlier — the same 1.70 at the first and the ninth, because no second term survives. Quote this rather than asserting either table is correct; the two best-known published sources differ from each other by 1.04 days on that same birth."Output schema / properties / result / properties / yearLengthDays / descriptionPrevious value: -"The length of a Vimshottari year in days. A CONVENTION, not a measurement — software using a different one will disagree with these dates by a growing amount across the cycle. Published so the disagreement is explicable rather than mysterious."New value: +"The length of a Vimshottari year in days. The classical text gives the periods and the order and never states one, so this is a CONVENTION: it is the true sidereal year, which is what Drik Panchang requests from its own API and what Jagannatha Hora defaults to. Software stepping a different year — the Julian 365.25, for instance — disagrees by an amount that grows across the cycle, about 0.76 days by the far end for that one."find_eclipses1 field changedOutput schema / properties / result / properties / upcoming / items / properties / obscuration / descriptionPrevious value: -"Fraction of the disc covered at greatest eclipse, 0 to 1."New value: +"Fraction of the disc covered at greatest eclipse, 0 to 1. Null for a partial SOLAR eclipse, where the quantity is not defined without an observer — give a place and read local.obscuration instead."compute_transitscompute_vimshottari_dashaget_planetary_positionscheck_retrogrades1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "bodies": {
+ "items": {
+ "properties": {
+ "currentPeriodEnd": {
+ "description": "The station that closes it. Same shape, same null rule.",
+ "type": "object"
+ },
+ "currentPeriodStart": {
+ "description": "The station that OPENED the period this body is currently in — its type, its exact UTC instant, and the degree it stationed at. null when no station falls inside the search window, which the page says rather than leaving blank. This field and the next are the reason to call this endpoint instead of reading a speed.",
+ "type": "object"
+ },
+ "formattedDegree": {
+ "description": "Degree within the sign, for display.",
+ "type": "string"
+ },
+ "longitudeSpeedPerDay": {
+ "description": "Degrees of ecliptic longitude per day. Negative while retrograde; near zero at a station.",
+ "type": "number"
+ },
+ "planet": {
+ "description": "One of the eight bodies that can station.",
+ "type": "string"
+ },
+ "retrograde": {
+ "description": "Apparent motion at that instant.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "date": {
+ "description": "The date asked about.",
+ "type": "string"
+ },
+ "directNow": {
+ "description": "The bodies moving direct at that instant.",
+ "type": "array"
+ },
+ "excluded": {
+ "items": {
+ "properties": {
+ "bodies": {
+ "description": "What is deliberately not in the list: the Sun and Moon, which cannot station, and Rahu and Ketu, which move backwards every day of their existence.",
+ "type": "array"
+ },
+ "reason": {
+ "description": "Why, in full. Quote it if the user asks about any of those four rather than reporting an absence.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "instantUTC": {
+ "description": "The instant the speeds were read at. It matters within about a day of a station.",
+ "type": "string"
+ },
+ "retrogradeNow": {
+ "description": "The names only, for a caller that wants the one-line answer. Empty when nothing is retrograde, which is itself the answer.",
+ "type": "array"
+ }
+}compute_birth_chart1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "omittedBodyNote": {
+ "description": "A sentence when a body we normally place is missing because our source for it does not reach this date. Chiron is the only such body: it comes from a JPL Horizons table covering 1920-01-01 to 2060-01-06, while this calculator accepts 1800 to 2200. Quote it rather than letting a reader conclude the body was placed and was unremarkable.",
+ "type": "object"
+ },
+ "origin": {
+ "properties": {
+ "clockChangeNote": {
+ "description": "A sentence when this wall-clock time occurred twice, or never occurred, because clocks changed that day. Says which of the two instants was used and how far the ascendant moves if the other was meant. Quote it with the offset.",
+ "type": "object"
+ },
+ "dstRuleNote": {
+ "description": "A sentence when a pre-1967 United States summer offset is inherited from the town the zone is named after rather than recorded for the birthplace. Names that town and the standard-time alternative. Quote it with the offset.",
+ "type": "object"
+ },
+ "historicNote": {
+ "description": "A sentence when a historic zone reassignment was applied, null when none was. Worth surfacing: it is the difference between a right and a wrong ascendant.",
+ "type": "object"
+ },
+ "latitude": {
+ "description": "The resolved latitude, never a default.",
+ "type": "number"
+ },
+ "localMeanTimeNote": {
+ "description": "A sentence when standard time had not yet reached this place, so the offset is mean time computed from the birthplace's own meridian. Names the longitude used and how far it is from the one the time zone database would have used. Quote it with the offset.",
+ "type": "object"
+ },
+ "longitude": {
+ "description": "The resolved longitude.",
+ "type": "number"
+ },
+ "offsetLabel": {
+ "description": "That zone's offset at that instant, written out.",
+ "type": "string"
+ },
+ "timezone": {
+ "description": "The IANA zone resolved for the birth DATE, not for today.",
+ "type": "string"
+ },
+ "utcInstant": {
+ "description": "The instant the chart was cast for, in UTC. Everything else follows from it.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "timeKnown": {
+ "description": "false when no birth time was given. The ascendant and houses are then absent rather than guessed.",
+ "type": "boolean"
+ },
+ "vedic": {
+ "properties": {
+ "nakshatra": {
+ "description": "The lunar mansion the Moon occupied AT THE BIRTH INSTANT. A point-in-time fact with no interval attached, which is what makes it different from the panchang tool's nakshatra: that one is the mansion running over a stretch of a given day and carries the instants it begins and ends. A birth chart has no validity window, so this field has no boundaries and should not be quoted as though it did.",
+ "type": "string"
+ },
+ "planets": {
+ "items": {
+ "properties": {
+ "sign": {
+ "description": "The same instant read against the sidereal zodiac, Lahiri ayanamsa.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "western": {
+ "properties": {
+ "ascendantFormatted": {
+ "description": "The ascendant in degrees and minutes. Absent when the birth time is unknown.",
+ "type": "string"
+ },
+ "houseSystem": {
+ "description": "Which house system produced the cusps. Placidus below about 66.06 degrees of latitude, Porphyry at or above it, where Placidus is undefined. Null when the birth time is unknown. Quote this rather than assuming Placidus.",
+ "type": "string"
+ },
+ "houses": {
+ "description": "Twelve house cusps, in the system named by result.western.houseSystem. Empty when the birth time is unknown.",
+ "type": "array"
+ },
+ "moonSign": {
+ "description": "Tropical moon sign.",
+ "type": "string"
+ },
+ "planets": {
+ "items": {
+ "properties": {
+ "formattedDegree": {
+ "description": "Degree within the sign, for display.",
+ "type": "string"
+ },
+ "longitude": {
+ "description": "Ecliptic longitude in degrees, 0 to 360 — the figure to compute with.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The body.",
+ "type": "string"
+ },
+ "retrograde": {
+ "description": "Apparent motion at that instant.",
+ "type": "boolean"
+ },
+ "sign": {
+ "description": "Its sign.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sunSign": {
+ "description": "Tropical sun sign.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+}compute_maya_day_sign1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "daySign": {
+ "properties": {
+ "name": {
+ "description": "The day sign in the conventional spelling.",
+ "type": "string"
+ },
+ "reformedSpelling": {
+ "description": "The same sign in the reformed Guatemalan orthography.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "haab": {
+ "properties": {
+ "written": {
+ "description": "The Haab date, e.g. \"3 Kankin\".",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "julianDayNumber": {
+ "description": "The Julian Day Number the conversion went through, so the arithmetic can be checked against any other implementation.",
+ "type": "number"
+ },
+ "kin": {
+ "description": "Position in the 260-day Tzolk'in round, 1 to 260.",
+ "type": "number"
+ },
+ "longCount": {
+ "description": "The Long Count on the GMT correlation constant 584283.",
+ "type": "string"
+ },
+ "tone": {
+ "description": "The tone, 1 to 13.",
+ "type": "number"
+ },
+ "tzolkinDate": {
+ "description": "Tone and sign together, e.g. \"4 Ahau\".",
+ "type": "string"
+ }
+}compute_moon_phase1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "illuminatedFraction": {
+ "description": "Fraction of the disc lit, 0 to 1. The real one for this instant, not an eighth-of-a-cycle approximation.",
+ "type": "number"
+ },
+ "instantUTC": {
+ "description": "The instant the phase was computed for, in UTC. The phase moves measurably within a day, so this is not decoration.",
+ "type": "string"
+ },
+ "lunation": {
+ "items": {
+ "properties": {
+ "daysFromQuery": {
+ "description": "Days from the instant asked about. Negative for a phase already past.",
+ "type": "number"
+ },
+ "phase": {
+ "description": "One of the four principal phases bracketing this instant: New Moon, First Quarter, Full Moon, Last Quarter.",
+ "type": "string"
+ },
+ "utc": {
+ "description": "The exact instant of that phase, to the second, found by search rather than interpolation.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "moon": {
+ "properties": {
+ "distanceKm": {
+ "description": "Geocentric distance in kilometres. The Moon is not always the same size.",
+ "type": "number"
+ },
+ "formattedDegree": {
+ "description": "Its degree within that sign, for display.",
+ "type": "string"
+ },
+ "sign": {
+ "description": "The Moon's tropical sign.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "moonAgeDays": {
+ "description": "Days since the new moon that opened this lunation. Computed from the real new moon, not from a mean synodic month, which varies by up to thirteen hours either side.",
+ "type": "number"
+ },
+ "nextFullMoonUTC": {
+ "description": "The next full moon after this instant.",
+ "type": "string"
+ },
+ "nextNewMoonUTC": {
+ "description": "The next new moon after this instant.",
+ "type": "string"
+ },
+ "phaseAngle": {
+ "description": "Elongation of the Moon from the Sun in degrees: 0 at new, 90 at first quarter, 180 at full, 270 at last quarter.",
+ "type": "number"
+ },
+ "phaseName": {
+ "description": "The eight-fold name a reader expects, e.g. \"Waxing Gibbous\".",
+ "type": "string"
+ },
+ "range": {
+ "description": "null unless a `to` date was given. When present it carries from, to and every principal phase between them.",
+ "type": "object"
+ },
+ "waxing": {
+ "description": "True while the illuminated fraction is growing.",
+ "type": "boolean"
+ }
+}compute_panchang1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "ayanamsa": {
+ "description": "The ayanamsa the sidereal longitudes were taken on.",
+ "type": "string"
+ },
+ "date": {
+ "description": "The civil date the limbs were read for, at the place given.",
+ "type": "string"
+ },
+ "dayLengthHours": {
+ "description": "Hours between sunrise and sunset.",
+ "type": "number"
+ },
+ "karana": {
+ "properties": {
+ "endLocal": {
+ "description": "When it ends, carrying its date and its UTC offset. A karana is half a tithi, so it runs about 10 to 13.4 hours and two of them end within most civil days.",
+ "type": "string"
+ },
+ "endUTC": {
+ "description": "The same end boundary as a UTC instant to the second.",
+ "type": "string"
+ },
+ "lengthHours": {
+ "description": "How long this karana runs, in hours. Always about half the tithi it sits in, and every second karana ends exactly where its tithi does.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The karana, the half-tithi.",
+ "type": "string"
+ },
+ "startLocal": {
+ "description": "When this karana began, on the local clock, carrying its date and its UTC offset. The date is on it because a karana boundary can fall on a different civil day from the date you asked about.",
+ "type": "string"
+ },
+ "startUTC": {
+ "description": "The same start boundary as a UTC instant to the second.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "masa": {
+ "properties": {
+ "adhika": {
+ "description": "True in an intercalary month.",
+ "type": "boolean"
+ },
+ "amanta": {
+ "description": "The lunar month on the new-moon-to-new-moon reckoning used across southern and western India.",
+ "type": "string"
+ },
+ "purnimanta": {
+ "description": "The same month on the full-moon-to-full-moon reckoning used across the north. The two names differ for half of every month, which is why both are returned rather than one being chosen.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "nakshatra": {
+ "properties": {
+ "endLocal": {
+ "description": "When it ends, carrying its date and its UTC offset. A nakshatra runs about 20.8 to 27.2 hours, the longest of the four, so its span contains a local midnight 97 per cent of the time — more often than any other limb — and this boundary frequently falls on the day AFTER the date asked about. For New Delhi on 2026-09-20 it is 2026-09-21. Quote the date with the time.",
+ "type": "string"
+ },
+ "endUTC": {
+ "description": "The same end boundary as a UTC instant to the second.",
+ "type": "string"
+ },
+ "lengthHours": {
+ "description": "How long this nakshatra runs, in hours — about 20.8 to 27.2 hours, averaging 24.3. Never a flat 24, because the Moon's speed varies through its orbit.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The Moon's nakshatra at sunrise.",
+ "type": "string"
+ },
+ "pada": {
+ "description": "Which quarter of the nakshatra, 1 to 4.",
+ "type": "number"
+ },
+ "startLocal": {
+ "description": "When this nakshatra began, on the local clock, carrying its date and its UTC offset — \"2026-09-20 01:42 UTC+5:30\". The date is on it because a nakshatra boundary can fall on a different civil day from the date you asked about.",
+ "type": "string"
+ },
+ "startUTC": {
+ "description": "The same start boundary as a UTC instant to the second.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "place": {
+ "properties": {
+ "label": {
+ "description": "The place as it was resolved. Compare it with what you sent: a panchang is a question about a place, and the wrong place is a different day's answer.",
+ "type": "string"
+ },
+ "latitude": {
+ "description": "The resolved latitude.",
+ "type": "number"
+ },
+ "longitude": {
+ "description": "The resolved longitude. This is the one that moves the answer — it sets the sunrise the whole reading hangs on.",
+ "type": "number"
+ },
+ "timezone": {
+ "description": "The IANA zone resolved for that place on that date, used only for the local clock times.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "sunriseLocal": {
+ "description": "The same instant on the clock at that place, which is how a printed panchang gives it.",
+ "type": "string"
+ },
+ "sunriseUTC": {
+ "description": "The instant the day's limbs are read at. Everything below is true AT THIS MOMENT, which is the classical rule rather than a convenience.",
+ "type": "string"
+ },
+ "sunsetLocal": {
+ "description": "Sunset on the local clock.",
+ "type": "string"
+ },
+ "tithi": {
+ "properties": {
+ "endLocal": {
+ "description": "When it ends, carrying its date and its UTC offset. A tithi is not a day: it runs about 20 to 26.8 hours, averaging 23.6 and ends at an arbitrary clock time, which is the whole reason the sunrise rule exists — and why this boundary frequently falls on the following day.",
+ "type": "string"
+ },
+ "endUTC": {
+ "description": "The same end boundary as a UTC instant to the second.",
+ "type": "string"
+ },
+ "lengthHours": {
+ "description": "Its actual length in hours.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The lunar day running at sunrise.",
+ "type": "string"
+ },
+ "paksha": {
+ "description": "Shukla (waxing) or Krishna (waning).",
+ "type": "string"
+ },
+ "startLocal": {
+ "description": "When this tithi began, on the local clock, carrying its date and its UTC offset — \"2026-09-20 17:51 UTC+5:30\". A tithi boundary crosses midnight routinely, so a bare clock time would be ambiguous by a full day.",
+ "type": "string"
+ },
+ "startUTC": {
+ "description": "The same start boundary as a UTC instant to the second.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "vara": {
+ "properties": {
+ "name": {
+ "description": "The weekday, counted from sunrise rather than from midnight.",
+ "type": "string"
+ },
+ "sanskrit": {
+ "description": "Its Sanskrit name, e.g. Ravivara.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "yoga": {
+ "properties": {
+ "endLocal": {
+ "description": "When it ends, carrying its date and its UTC offset. The summed longitudes move faster than any other panchang quantity, so a yoga is the shortest of the four spans at about 19.5 to 25.2 hours. Its boundary still lands on a different civil day from its start 93.4 per cent of the time, because a span only has to be long enough to reach a midnight.",
+ "type": "string"
+ },
+ "endUTC": {
+ "description": "The same end boundary as a UTC instant to the second.",
+ "type": "string"
+ },
+ "lengthHours": {
+ "description": "How long this yoga runs, in hours.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The yoga, from the summed sidereal longitudes of Sun and Moon.",
+ "type": "string"
+ },
+ "startLocal": {
+ "description": "When this yoga began, on the local clock, carrying its date and its UTC offset. The date is on it because a yoga boundary can fall on a different civil day from the date you asked about.",
+ "type": "string"
+ },
+ "startUTC": {
+ "description": "The same start boundary as a UTC instant to the second.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+}compute_tarot_birth_card1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "card": {
+ "description": "The tarot birth card.",
+ "type": "string"
+ },
+ "compound": {
+ "description": "The compound number before the final reduction.",
+ "type": "number"
+ },
+ "numeral": {
+ "description": "Its Roman numeral in the Rider-Waite-Smith trumps.",
+ "type": "string"
+ },
+ "reduced": {
+ "description": "The reduced destiny number.",
+ "type": "number"
+ },
+ "root": {
+ "description": "The root the card is taken from.",
+ "type": "number"
+ },
+ "steps": {
+ "items": {
+ "properties": {
+ "label": {
+ "description": "What this line of the arithmetic does.",
+ "type": "string"
+ },
+ "working": {
+ "description": "The arithmetic itself, so the answer can be checked by hand.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+}convert_calendar_date1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "calendarDivergenceDays": {
+ "description": "How many days the Julian calendar has fallen behind the Gregorian one on this day: ten at the 1582 reform, thirteen through the twentieth and twenty-first centuries. The number a pre-reform source is usually out by.",
+ "type": "number"
+ },
+ "correlationConstant": {
+ "description": "584283, the Goodman–Martinez–Thompson constant. Returned with every answer because there is no such thing as \"the\" Maya date for a Gregorian date without naming one.",
+ "type": "number"
+ },
+ "gregorian": {
+ "properties": {
+ "iso": {
+ "description": "The proleptic Gregorian date, YYYY-MM-DD.",
+ "type": "string"
+ },
+ "weekday": {
+ "description": "The day of the week, computed from the day count rather than from a Date object.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "inputKind": {
+ "description": "Which of the four starting points the request used: gregorian, julian-day-number, long-count or julian-calendar. Echoed so you can tell that the converter read your input the way you meant it.",
+ "type": "string"
+ },
+ "inputValue": {
+ "description": "That input as it was understood, normalised.",
+ "type": "string"
+ },
+ "julianCalendar": {
+ "properties": {
+ "iso": {
+ "description": "The same day in the Julian calendar. Not the same string as the Gregorian one for any date since 200 CE.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "julianDayNumber": {
+ "description": "The Julian Day Number every conversion goes through. This is the figure to check against another implementation, because everything else is derived from it.",
+ "type": "number"
+ },
+ "maya": {
+ "properties": {
+ "calendarRound": {
+ "description": "The Tzolk'in and Haab pair, which repeats every 18,980 days. This is what the round search looks for.",
+ "type": "string"
+ },
+ "daysSinceEpoch": {
+ "description": "Days elapsed since the correlation epoch. Negative before it.",
+ "type": "number"
+ },
+ "haab": {
+ "description": "The Haab date, e.g. \"3 Kankin\".",
+ "type": "string"
+ },
+ "longCount": {
+ "description": "The Long Count in baktun.katun.tun.uinal.kin form.",
+ "type": "string"
+ },
+ "tzolkin": {
+ "description": "Tone and day sign together, e.g. \"4 Ahau\".",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "roundSearch": {
+ "description": "null unless a Calendar Round search was asked for. When present it carries the query, the year range, a matches array and a truncated flag.",
+ "type": "object"
+ }
+}find_eclipses1 field changedOutput schema / properties / result / propertiesAdded value: +{
+ "date": {
+ "description": "The date searched around, not a date an eclipse falls on.",
+ "type": "string"
+ },
+ "family": {
+ "description": "both, lunar or solar — what was actually listed.",
+ "type": "string"
+ },
+ "nearest": {
+ "description": "The eclipse nearest the date in either direction, so a caller wanting one answer does not have to compare two arrays. null only when the search found nothing at all.",
+ "type": "object"
+ },
+ "place": {
+ "description": "null when no place was given. When present, every listing also carries a `local` block, and only then does the answer say anything about what somebody would SEE.",
+ "type": "object"
+ },
+ "previous": {
+ "items": {
+ "properties": {
+ "kind": {
+ "description": "total, annular, partial, penumbral, or hybrid.",
+ "type": "string"
+ },
+ "peakUTC": {
+ "description": "Greatest eclipse, to the second in UTC, for an eclipse before the date.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "upcoming": {
+ "items": {
+ "properties": {
+ "daysFromQuery": {
+ "description": "Days from the date asked about.",
+ "type": "number"
+ },
+ "greatestAt": {
+ "description": "Where greatest eclipse touches the Earth, as latitude and longitude. Solar only; null for a lunar eclipse.",
+ "type": "object"
+ },
+ "label": {
+ "description": "A readable name for the event, e.g. \"total solar eclipse\".",
+ "type": "string"
+ },
+ "local": {
+ "description": "null unless a place was given. When present: the local kind, which can be weaker than the global one, the local clock times of first contact, maximum and last contact, and the altitude of the body at each — because \"the Moon sets partway through\" and \"it is already underway at moonrise\" are different sentences and only one of them is actionable.",
+ "type": "object"
+ },
+ "nakedEye": {
+ "description": "Whether there is something a person could actually see. A penumbral lunar eclipse is a real event and very nearly nothing to look at.",
+ "type": "boolean"
+ },
+ "obscuration": {
+ "description": "Fraction of the disc covered at greatest eclipse, 0 to 1.",
+ "type": "number"
+ },
+ "peakUTC": {
+ "description": "The same for an eclipse after the date.",
+ "type": "string"
+ },
+ "sign": {
+ "description": "The zodiac sign of the eclipsed body — the Moon for lunar, the Sun for solar.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+}check_retrogradescompute_birth_chartcompute_maya_day_signcompute_moon_phasecompute_panchangcompute_tarot_birth_cardconvert_calendar_datefind_eclipsesWestern, Vedic, and Chinese astrology calculations, charts, forecasts, and geocoding.
Vedic astrology from a real ephemeris: birth chart, life-event timing and Kundli matching.
Observatory-grade Indian astronomy, years -5000..+5000: positions, eclipses, panchang date search.
Swiss Ephemeris for AI agents: exact natal charts, transits, synastry and birth-place resolution
Add one secure layer between your agents and this server.
