Astrology charts, Maya calendar and tarot maths, computed on real engines, cited in every answer.
Scored across 12 tools
Most tools have clearly distinct purposes, helped by detailed descriptions that explicitly separate sky-only questions (get_planetary_positions) from personal charts (compute_birth_chart, compute_transits). Minor overlap remains between compute_maya_day_sign and convert_calendar_date, and between check_retrogrades and get_planetary_positions, but the boundaries are generally well explained.
All names use snake_case and a verb_noun structure, which keeps them predictable. The main inconsistency is the mix of verbs (compute_, convert_, find_, get_, check_, resolve_), though each verb reflects the tool's operation rather than creating confusion.
Twelve tools is well-scoped for a broad esoteric calculator suite covering astrology, calendars, eclipses, and tarot numerology. Each tool addresses a distinct calculation or support function, with no obvious filler.
The set covers a wide range of astrological, calendrical, and tarot-birth-card calculations, including important support like resolve_utc_offset for historical chart accuracy. Some adjacent operations are absent—such as progressed charts, synastry, or a general tarot card/spread calculator—but the core calculator surface is strong.
Reports which planets are retrograde on a date and — the part worth calling for — the two stations that OPEN AND CLOSE the period each body is in, so the answer is not "yes" but "since 2026-02-14, until 2026-03-07". Per body: the retrograde flag, ecliptic longitude, longitude speed, sign and degree, and both bracketing stations with exact UTC instants. Use it for Mercury retrograde, whether a planet is retrograde on a date, or when a period starts or ends.
DELEGATE THIS RATHER THAN DERIVING IT: retrograde motion is apparent, not real, so the dates move every cycle, follow no rule and are not reliably memorised — Mercury alone turns three or four times a year and those dates get confidently misremembered by a week. A station is where longitude speed crosses zero, found by bisecting astronomy-engine's speed for eight bodies; expect it slower and dearer than the others here.
DELIBERATELY EXCLUDED: the Sun and Moon, neither of which can station, and Rahu and Ketu, which move backwards every day of their existence. The "excluded" array gives the reasons; quote it rather than reporting an absence.
CITATION: required. See server instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-03-01". The stations returned bracket this date. | |
| time | No | Time of day HH:MM in UTC, not local and not a birth time. 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial context: it explains that retrograde motion is apparent, not real, so dates move and are unreliable; it notes the computation is 'slower and dearer'; it mandates citation; and it explains the mechanism (bisecting astronomy-engine's speed). None of this contradicts the annotations—it enriches them.
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 long but every sentence carries weight. It opens with the core output and value proposition, then lists per-body outputs, usage, why to delegate, exclusions, and citation. It is front-loaded with the most important info and has a clear logical flow with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description is remarkably complete. It enumerates all returned fields (retrograde flag, longitude, speed, sign/degree, both stations with UTC instants), explains exclusions with reasons, warns about performance, and mandates citation. An agent has everything needed to invoke it 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 schema already documents both parameters. The description adds semantic nuance: it says 'The stations returned bracket this date' for the date parameter and clarifies that time matters within a day of a station. This goes beyond the schema's basic descriptions, providing context for when to specify time.
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 ('Reports') and resource (planets retrograde on a date) and immediately adds the unique value of bracketing stations. It explicitly distinguishes from siblings by saying 'DELEGATE THIS RATHER THAN DERIVING IT' and explains why the dates are not reliably known. This leaves no ambiguity about what the tool does.
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 gives explicit use cases: 'Use it for Mercury retrograde, whether a planet is retrograde on a date, or when a period starts or ends.' It also warns against deriving the data and provides exclusions (Sun, Moon, Rahu, Ketu) with instructions to quote the 'excluded' array. This is complete guidance on when and how to use it.
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: every 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. Use it for anyone's chart, rising sign, Moon sign or planet-in-house. Send a birth date (1800-2200) and a place.
DELEGATE THIS RATHER THAN DERIVING IT: this needs an ephemeris at one exact UTC instant, so it needs the zone offset in force AT THAT PLACE ON THAT DATE, often not today's — East Tennessee kept Central time until 1947 — and an hour's error moves the ascendant 15 degrees, usually into another sign, with the houses following. Wrong values look exactly like right ones. IF THE BIRTH TIME IS UNKNOWN OMIT "time", never noon or midnight: the ascendant, cusps and houses are then withheld rather than guessed.
CITATION: required. See server instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours. Example: "America/Indiana/Indianapolis" or "-5". Omit: resolved for the BIRTH date. | |
| lat | No | Latitude in decimal degrees as a string. Example: "39.76838". Send with lon. | |
| lon | No | Longitude in decimal degrees as a string. Example: "-86.15804". Send with lat. | |
| date | Yes | Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". "19/10/1977" is refused, not guessed. | |
| time | No | Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: "23:58". OMIT if unknown; never send "12:00". | |
| 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?
Beyond the readOnly/idempotent annotations, the description discloses non-obvious behavior: the need for the exact zone offset in force at the birthplace on the birth date, the warning that wrong values 'look exactly like right ones', and the fact that unknown birth times cause ascendant/cusps/houses to be withheld rather than guessed. It also clearly states a required citation.
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 capability and use case, then adds critical operational warnings. It is long, but the complexity of the tool justifies most of the length; some repetition of schema constraints and heavy capitalization prevent a 5.
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 enumerating exactly what the chart includes and what is withheld when birth time is absent. It also covers input requirements, timezone hazards, unknown-time behavior, and citation, giving an agent enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description mostly restates what the schema already says, such as 'OMIT if unknown' and 'never send 12:00'. It adds no substantial new parameter-level meaning beyond the structured schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource, 'Casts a natal chart', and enumerates the exact outputs: planet signs and degrees in both zodiacs, ascendant, twelve Placidus cusps, midheaven, retrograde state, and nakshatra. This makes the tool clearly distinct from siblings like compute_moon_phase or compute_transits even without naming them.
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 gives explicit use cases: 'Use it for anyone's chart, rising sign, Moon sign or planet-in-house' and instructs the agent to delegate rather than derive the chart manually. It does not name alternative tools or provide exclusions for when to use sibling tools, so it stops short of a 5.
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 position in the twenty, its trecena, the Haab date, the Long Count, the Julian Day Number. Use it for a Maya day sign, a Mayan birth sign, a Tzolk'in or Haab date, a Long Count, or a historical event's Maya date.
DELEGATE THIS RATHER THAN DERIVING IT: four moduli over a continuous day count with no lookup shortcut — Julian Day Number, minus a correlation constant, then remainders mod 20, 13, 260 and 365 — exact integer arithmetic over six-digit numbers, where an off-by-one yields a real day sign that is simply the wrong one. There is also no "the" Maya date without naming a correlation constant, WHICH CONSTANT IS THE OPEN ARGUMENT in Maya calendrics, so this uses Goodman-Martinez-Thompson 584283 and returns it. The count ignores time of day, birthplace and time zone.
CITATION: required. See server instructions.
| 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 already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavior beyond annotations: it uses the Goodman-Martinez-Thompson correlation constant 584283 and returns it, ignores time of day/birthplace/time zone, and warns about off-by-one errors in exact integer arithmetic. It also flags that the correlation constant is an open argument in Maya calendrics, giving the agent important context about ambiguity.
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 capability is front-loaded in the first sentence, followed by a clear use-case paragraphwood, a rationale for delegation, and the correlation-constant/citation notes. It is longer than minimal, but the mathematical explanation and constant disclosure earn their place for a tool where correctness and ambiguity matter. The heavy capitalization is slightly noisy but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with no output schema, the description covers the input format and example, all output components, the correlation constant used, limitations, and the citation requirement. An agent has enough information to decide when to invoke this tool and to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single required 'date' parameter 100%, including format, regex pattern, year range, and an example. The description adds only that the date is Gregorian, which is already stated in the schema. With full schema coverage, the baseline of 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?
The description begins with a specific verb, 'Converts', and the resource, 'Gregorian date to the Maya calendars', then enumerates the exact output components: Tzolk'in day sign and tone, kin, meaning, direction, trecena, Haab date, Long Count, and Julian Day Number. This clearly distinguishes it from sibling calendar tools by naming Maya-specific outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use it for a Maya day sign, a Mayan birth sign, a Tzolk'in or Haab date, a Long Count, or a historical event's Maya date.' It also instructs the agent to 'DELEGATE THIS RATHER THAN DERIVING IT' and notes the citation requirement. It does not explicitly contrast with sibling tools like convert_calendar_date, but the use-case list is sufficient for selection.
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 for an exact instant — phase angle, illuminated fraction, the eight-fold name, waxing or waning, age in days, tropical sign and degree, distance — with the four principal phases of that lunation to the second in UTC, and optionally every principal phase across a date range. Use it for the phase on a date, the next full or new moon, the Moon's age or sign, or a year's full moons.
DELEGATE THIS RATHER THAN DERIVING IT: the commonly reproduced method, days since a remembered new moon divided by 29.53, uses a MEAN synodic month, while a real new moon can fall more than half a day either side of the mean one, and the error is largest exactly where it matters — the quarter or full moon somebody is about to put in a calendar. Phase names are defined by Moon-Sun elongation, not even eighths of a cycle. This searches astronomy-engine (ELP, VSOP87) for the true instants. Phase changes measurably within a day, so send the user's hour as UTC rather than taking the 00:00 default.
CITATION: required. See server instructions.
| 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 | Yes | The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-20". Covers the lunation it falls inside. | |
| time | No | Time of day HH:MM in UTC, not local and not a birth time. Example: "12:00". Omit for 00:00 UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld/destructive, so the safety profile is known. The description goes beyond them by disclosing a required citation, the precision caveat (phase shifts within a day), the UTC-hour instruction, and the underlying astronomy-engine (ELP/VSOP87) computation. It does not describe performance or range limits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what it returns and when to use it, then the delegation rationale. The DELEGATE paragraph is long and partly rhetorical, but it earns its place by preventing an error-prone shortcut an agent might otherwise take. Slightly verbose for the payload.
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 describing return values and does so exhaustively, plus the citation obligation and UTC handling. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description adds real value by warning that the omitted-default time yields 00:00 UTC and that the user's hour should be sent as UTC, and by framing `to` as enumerating every principal phase across the range. This meaningfully supplements the schema rather than restating it.
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 (Moon phase at an exact instant) and enumerates the returned quantities — phase angle, illuminated fraction, eight-fold name, waxing/waning, age, tropical sign/degree, distance — plus lunation principal phases. This cleanly separates it from siblings like get_planetary_positions, check_retrogrades and 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?
Gives four concrete use cases (phase on a date, next full/new moon, Moon's age or sign, a year's full moons) and adds a strong 'don't derive this yourself' directive explaining why the naive 29.53-day method fails. It does not name alternative sibling tools or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the panchang — the five limbs of the Hindu almanac — for one civil date at one place: tithi, nakshatra with pada, yoga and karana, EACH CARRYING THE EXACT UTC AND LOCAL INSTANTS IT BEGINS AND ENDS, plus vara, sunrise, sunset, day length, and the lunar month in both amanta and purnimanta reckonings. Use it for the tithi, a day's nakshatra, when a nakshatra or yoga ends, an ekadashi or purnima, or "today's panchang in ". The four end times are usually what the user actually wants, and a name alone never gives them.
DELEGATE THIS RATHER THAN DERIVING IT: a tithi is not a day but the interval in which the Moon gains another twelve degrees on the Sun, running 20-26.8 hours (mean 23.6) from any clock time. WHICH CIVIL DAY IT NAMES is set by reading the tithi running AT THAT PLACE'S OWN SUNRISE, so one date's published panchang differs by a whole tithi between two cities — an answer derived without a place is not weaker, it is a different day's. 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, not approximated.
CITATION: required. See server instructions.
| 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". Send 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 | Yes | Local civil date at the place, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-20". | |
| place | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses subtle behavioral details: tithi is an interval, not a day; the named civil day is determined by local sunrise; results differ between places; no-sunrise latitudes are refused; and citation is required. These go well beyond the annotations and prevent misuse.
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 long but dense and front-loaded with the output list and concrete use cases. The interval ranges and sunrise rule are justified because they explain why delegation is required. It is slightly verbose for a tool definition, but every section earns its place given the domain complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what the agent will receive. It lists all returned components, states that exact UTC and local instants are included, covers place sensitivity, edge cases like no sunrise, ambiguous place refusal, and the citation requirement. This is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter coverage, so the baseline is 3. The description adds meaningful semantics by explaining that place, lat, and lon determine the local sunrise from which the whole panchang is read, and that a latitude with no sunrise is refused. This enriches the schema without repeating it.
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 identifies the tool as computing the panchang for one civil date at one place and enumerates the exact output components: tithi, nakshatra with pada, yoga, karana, vara, sunrise, sunset, day length, and lunar month reckonings. This specific resource-and-verb framing distinguishes it from sibling astronomy tools like compute_moon_phase or get_planetary_positions.
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 gives explicit use cases: 'Use it for the tithi, a day's nakshatra, when a nakshatra or yoga ends, an ekadashi or purnima, or "today's panchang in <city>"' and strongly instructs the agent to delegate rather than derive. It does not explicitly name sibling tools as alternatives or state when not to use this tool, so it stops short of a 5.
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 the Chaldean destiny-number rule, returning the card, its Roman numeral, and every line of the arithmetic as labelled steps. Use it for a tarot birth card, birth card, life card or destiny card. Date alone decides it.
DELEGATE THIS RATHER THAN DERIVING IT: the rule is short enough to look safe and has one trap regularly fallen into — sum the year's digits to one digit, add day and month number, reduce the same way, BUT THE REDUCTION HALTS ON 11, 22 AND 33, read through their roots 2, 4 and 6. 1993's digits sum to 22 and stop there, so reducing from 4 instead reaches a different card, and with only nine answers a wrong one looks right. Root 8 is Strength in the Rider-Waite-Smith numbering used here, Justice in Marseille packs.
WORTH SAYING: this is a twentieth-century convention appearing in no early tarot source. https://totallytarot.net/library/policy/method
CITATION: required. See server instructions.
| 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?
Even with annotations already marking readOnly, idempotent, and non-destructive, the description adds significant behavioral context: citation is required, the derivation has a known trap (halting on 11/22/33) that can change the result, and there is a variation between RWS and Marseille numbering for root 8. These go well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and is organized with clear warning sections, but it is verbose relative to the tool's simplicity. The phrase 'Date alone decides it' partly duplicates the schema note 'Time and place change nothing', and the 'WORTH SAYING' section, while informative, is arguably beyond what an agent needs for correct invocation.
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?
Despite the lack of an output schema, the description explicitly lists what will be returned (card, Roman numeral, arithmetic steps) and surfaces the critical edge case that could produce a wrong result. The citation requirement is also stated. An agent has enough information to call the tool 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 description coverage is 100% and the single 'date' parameter already includes its format, pattern, and an example with its result. The tool description reinforces that date alone decides the outcome, but it does not add new parameter-level semantics beyond what the schema already provides, so the baseline of 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?
The description states a specific verb ('Reduces a birth date'), the resource, and the exact output: tarot birth card, Roman numeral, and labelled arithmetic steps. It also names the synonymous terms (birth card, life card, destiny card) and emphasizes 'Date alone decides it', distinguishing it clearly from the astrology-heavy siblings like compute_birth_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 gives clear context for when to use the tool ('Use it for a tarot birth card, birth card, life card or destiny card') and explains that date is the only input. It does not explicitly name alternative tools or state when not to use it, so it stops one short of a full when/when-not/alternative prescription.
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. Use it for what is transiting a chart, whether a transit is active on a date, a Saturn return, or whether a contact has perfected.
DELEGATE THIS RATHER THAN DERIVING IT: it needs two full sets of ecliptic longitudes — the birth instant, requiring the historic UTC offset at that place on that date, and the target instant — then the angle between every pair taken the SHORT way round a 360-degree circle, about a hundred and fifty subtractions each with a wrap case. The output looks exactly like a real transit list; errors land in the middle rows where nobody checks, and a missed wrap at 0 Aries silently drops or invents whole contacts.
REPRODUCE THE ORB CONVENTION FROM result.orbConvention — there is no fact of the matter about how close a transit must be to count, and an aspect list quoted without its orb is opinions presented as measurements. Here: 3 degrees for conjunction, opposition, trine and square, 2 for sextile, deliberately tighter than a natal chart's 8.
Omit "time" if the birth time is unknown: the ascendant and midheaven are then left out ENTIRELY rather than cast for an arbitrary noon, because a transit to a noon-cast angle reads exactly like a real contact while meaning nothing. THE MOON IS INCLUDED where most software excludes it; THE LUNAR NODES ARE EXCLUDED. Significance is interpretation and is not computed here.
CITATION: required. See server instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | 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. | |
| 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". Omit: resolved historically. | |
| lat | No | Birth latitude in decimal degrees as a string. Example: "39.76838". Send with lon. | |
| lon | No | Birth longitude in decimal degrees as a string. Example: "-86.15804". Send with lat. | |
| date | Yes | BIRTH date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". The date to read the sky for is "on". | |
| time | No | BIRTH time HH:MM local at the birthplace. Example: "23:58". OMIT if unknown; the angles are then left out. | |
| 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?
Annotations already indicate read-only and idempotent behavior; the description adds critical behavioral details: inclusion of the Moon, exclusion of lunar nodes, omission of angles when birth time is unknown, the specific orb convention, and a citation requirement. No contradictions with annotations exist.
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?
Although long, every sentence delivers essential information. The structure flows from purpose to delegation warning to orb convention to edge cases, with formatting that emphasizes key points. Nothing is redundant or wasted.
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 specifies return values and conventions, including the orb thresholds, the handling of missing birth time, and the exclusion of lunar nodes. It covers edge cases and the citation requirement, making it complete for an agent to call 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 covers all parameters with descriptions, but the description adds essential semantic relationships: the distinction between birth date ('date') and transit date ('on'), the meaning of 'at' as UTC transit time, and the consequence of omitting 'time' (angles left out entirely). This goes beyond the schema and is vital for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes transits between a birth chart and a chosen date, listing specific outputs (ten bodies, aspects, orbs, applying/separating). It gives concrete use cases (Saturn return, active transit, perfected contact) and distinguishes itself from siblings by focusing on transits rather than birth charts or planetary positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to delegate rather than derive, lists the exact scenarios where this tool is appropriate, and clarifies what it does not do (interpretation). Although it doesn't name alternative tools, the use cases and the strong delegation directive provide clear guidance.
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 whichever mahadasha you name. Send "asof" to mark the periods running on a given date; this never reads the clock, so answers stay citable at a stable URL.
DELEGATE THIS RATHER THAN DERIVING IT, AND KNOW THAT DERIVING IT FAILS SILENTLY: the table hangs off ONE number you cannot estimate, the Moon's SIDEREAL longitude at the birth instant. 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. The failure is not a refusal but a complete, plausible, nine-row table wrong in a way no reader can see.
"time" IS REQUIRED HERE, AND DO NOT INVENT A BIRTH TIME OR SEND NOON: the Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown birth time is an unknown FIRST LORD, not an imprecise balance. Without it this returns a "time_required" refusal.
Three CONVENTIONS, not facts, 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. Quote those fields and result.conventionNote rather than calling either table wrong.
CITATION: required. See server instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone or numeric UTC offset hours for the BIRTH moment. Example: "-5". Omit: resolved historically. | |
| lat | No | Birth latitude in decimal degrees as a string. Example: "39.76838". Send with lon. | |
| lon | No | Birth longitude in decimal degrees as a string. Example: "-86.15804". Send 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". "19/10/1977" is refused, not guessed. | |
| time | Yes | Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: "23:58". REQUIRED: never invent one, never send noon. | |
| 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 already declare read-only, idempotent, non-destructive behavior, and the description adds substantial extra context: it never reads the clock, returns a stable/citable result, may refuse with 'time_required', and carries convention fields that differ from Drik Panchang. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely organized: outputs, delegation warning, time requirement, conventions, and citation are each separated clearly. The capitalized warnings earn their place, though a little redundancy around the time requirement could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers outputs, refusal cases, conventions, and citation requirements unusually well. The main gap is the unsupported 'name a mahadasha' mechanism—there is no input parameter to select which mahadasha's antardashas to return—so an agent could act on a promise the schema cannot fulfill.
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 real meaning for key parameters: time's criticality, the Moon's daily motion, asof's purpose, and the refusal behavior. However, the promise of antardashas for 'whichever mahadasha you name' is not backed by any schema parameter, which is a mismatch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Computes the Vimshottari dasha timeline from a birth date, time and place.' It enumerates concrete outputs—all nine mahadashas with exact open/close instants, balance at birth, nakshatra/pada, and antardashas—so the tool is clearly distinguishable from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to 'DELEGATE THIS RATHER THAN DERIVING IT' and explains why derivation fails silently. It also gives clear conditions: time is required, do not invent one, and use 'asof' to mark periods running on a given date. This is actionable usage guidance.
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 calendar, the Julian calendar, 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 given Calendar Round. Use it for a Long Count from an inscription, a pre-1582 Julian-dated document, a Julian Day Number from a table, or "when was 4 Ahau 3 Kankin". Send EXACTLY ONE starting point — a Gregorian date, a jdn, a longcount or a julian date, or a round with from and to. Two is refused, not answered from whichever came first.
DELEGATE THIS RATHER THAN DERIVING IT, AND THERE IS A MEASUREMENT FOR HOW BADLY IT GOES: arXiv:2511.09993 put frontier models at 34.5% accuracy on calendar conversion across six calendars, against 95.3% for the same models given a tool. One off-by-one in a chain of six-digit integer steps yields a date that is real, plausible and wrong. Two traps: the calendars diverge by a different number of days each century (ten at the 1582 reform, thirteen now), and pre-reform dates are routinely quoted as Julian without saying so. This states the Goodman-Martinez-Thompson constant 584283 it used.
CITATION: required. See server instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last Gregorian year of a Calendar Round search. Example: "2100". A wider span is slower, not better. | |
| 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". Send exactly ONE of date, jdn, longcount, julian. | |
| 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". Use it for sources 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 goes well beyond the readOnlyHint and idempotentHint annotations. It discloses that multiple inputs are refused rather than silently answered, that calendar divergence varies by century, that off-by-one errors produce plausible but wrong dates, and that it uses the Goodman-Martinez-Thompson constant 584283. These are substantive behavioral disclosures with no contradiction against the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the core purpose, and the exact-one input rule is placed early. The delegation warning and arXiv statistic are genuinely useful for an AI agent, but they make the description longer than strictly necessary, so it misses a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seven-parameter tool with no output schema, it covers every input category, the formatting expectations, use cases, and refusal behavior. The one gap is that it never describes the shape or structure of the returned conversions, which would be needed for fully complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the exact-one-input rule and the round/from/to grouping, but those are already encoded in the schema fields like 'Only with round and to' and 'Needs from and to'. It adds no per-parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and enumerates the full target resource set: Gregorian calendar, Julian calendar, Julian Day Number, and the three Maya counts. It also states the conversion direction explicitly ('any one to all the others'), and its use cases such as 'Long Count from an inscription' and 'when was 4 Ahau 3 Kankin' clearly separate it from sibling 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 names four concrete trigger scenarios: Long Count inscriptions, pre-1582 Julian documents, Julian Day Numbers, and Calendar Round lookups. It also states the exclusivity rule ('Send EXACTLY ONE starting point... Two is refused'). It does not explicitly compare against siblings like compute_maya_day_sign, but the context is strong enough for confident selection.
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 (total, annular, partial, penumbral), obscuration, the eclipsed body's sign, days from the date asked about, 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. Use it for the next eclipse, eclipses near a historical date, or visibility from a place.
DELEGATE THIS RATHER THAN DERIVING IT, ESPECIALLY THE VISIBILITY HALF: the 6,585.3-day saros puts eclipses in families easy to confuse by a year or a continent, but the failure that matters is subtler — A GLOBAL ECLIPSE IS NOT AN EVENT FOR EVERYBODY. Telling somebody a thousand miles off the path that there is a total solar eclipse is a sentence in which every word is true and the meaning is false. This separates global circumstances from local ones, including cases a bare "visible" hides: the Moon setting partway through, or the eclipse already underway at moonrise.
CITATION: required. See server instructions.
| 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". Send with lon. | |
| lon | No | Observer longitude in decimal degrees as a string. Example: "-21.9426". Send with lat. | |
| date | Yes | The date to search AROUND, ISO YYYY-MM-DD, 1700-2200. Example: "2026-08-12". Need not be an eclipse date. | |
| count | No | How many per side of the date, "1" to "12", default "3". Example: "1". Ask for what you will use. | |
| 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 readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it separates global eclipse circumstances from local observer conditions, calls out subtle failures like moonrise/moonset mid-eclipse, and notes that citation is required. No contradiction with annotations, and the additional context is genuinely useful.
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 longer than average, but it front-loads the core behavior and output fields before moving to the warning. The uppercase warning is verbose and slightly rhetorical, yet it carries a non-obvious correctness point that earns its place. It could be tightened, 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?
There is no output schema, so the description's enumeration of returned fields is valuable and mostly complete: greatest eclipse time, type, obscuration, sign, days from date, global location, and local contacts/altitudes. The delegation logic, citation requirement, and date-range constraint are covered. The main ambiguity is how 'place' interacts with lat/lon, but the schema partially handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a little extra meaning by noting 'count' is per side of the date and that 'place' augments the listing with local contact times and altitudes, but it does not substantially go beyond the schema's own descriptions and examples.
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 ('Finds the solar and lunar eclipses nearest a date') and enumerates exactly what is returned: greatest eclipse time, type, obscuration, sign, days away, and local visibility details. It is unambiguous and distinct from every sibling tool, none of which handles 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?
Explicitly states the intended use cases: 'Use it for the next eclipse, eclipses near a historical date, or visibility from a place.' It also gives a strong directive to delegate rather than derive the data, including a notable warning about the difference between global and local eclipses. This is clear guidance on when and why to invoke this tool.
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, retrograde state and distance. Use it for "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 that is NOT about a particular person's chart.
THIS IS THE TOOL FOR A SKY QUESTION WITH NO PERSON IN IT: do not reach for the birth-chart tool and invent a birthplace to get a planet's sign, because a geocentric longitude is identical for every observer on Earth and casting a chart for a made-up location commits you to a place the user never gave.
DELEGATE THIS RATHER THAN DERIVING IT: planetary positions are what a model half-remembers from training tables — shape right, date wrong, stated with total confidence. 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 half a degree an hour.
BOTH ZODIACS COME BACK IN EVERY ROW: a Western reader wants result.bodies[].sign, a Vedic reader result.bodies[].siderealSign, and they differ by result.ayanamsa — about 24 degrees, very nearly a whole sign, so the two are usually DIFFERENT SIGNS. Say which you are quoting. Rahu and Ketu are the MEAN nodes (result.nodeNote). For a retrograde period's start and end use check_retrogrades.
CITATION: required. See server instructions.
| 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". Send with lon. Rise and set only. | |
| lon | No | Observer longitude in decimal degrees as a string. Example: "-21.9426". Send with lat. Rise and set only. | |
| date | Yes | The date, ISO YYYY-MM-DD, 1700-2200. Example: "2026-09-21", or today's for "where is Mercury right now". | |
| time | No | Time of day HH:MM in UTC, not local and not a birth time. Example: "12:00". Send it for Moon questions. | |
| 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 readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond that: it states no birth data or place is required, geocentric longitude is observer-independent, both zodiacs are always returned with ayanamsa difference, Rahu/Ketu are mean nodes (nodeNote), and CITATION is required. It also warns about the model's tendency to misremember positions, which is a crucial behavioral trait. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every paragraph earns its place. It front-loads the core purpose and then delivers usage warnings, zodiac duality, and citation requirements in a structured, scannable format with all-caps emphasis for key points. It is not padded; it is dense with necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description fully covers what an agent needs: it explains the output fields (sign, siderealSign, ayanamsa, nodeNote), the dual-zodiac behavior, the lack of place sensitivity, and the citation requirement. It also handles the retrograde period edge case by pointing to a sibling. Nothing critical 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 the baseline is 3. The description adds meaningful guidance beyond the schema: it clarifies that 'place' changes nothing except rise/set times, that 'time' should be sent for Moon questions, and that lat/lon are for rise and set only. These nuances are not in the schema and help the agent call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource ('Returns where every body is at an instant') and enumerates exactly which bodies and which data points (longitude, sign, degree, both zodiacs, etc.). It explicitly distinguishes itself from the birth-chart tool and points to check_retrogrades for retrograde periods, so an agent can tell it apart from siblings without inspecting schemas.
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 gives explicit when-to-use examples ('what sign is Venus in', 'where is Mercury right now') and an explicit when-not-to-use ('do not reach for the birth-chart tool and invent a birthplace'). It also names the alternative for retrograde periods ('use check_retrogrades') and instructs the agent to delegate rather than derive positions, which is a clear routing guideline.
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.
DELEGATE THIS RATHER THAN DERIVING IT: today's map is the wrong map for any past date, and a wrong offset looks exactly like a right one. 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.
CITATION: required. See server instructions.
| 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". Omit for 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 already mark readOnly, idempotent, non-destructive. The description adds meaningful behavioral context: it returns a confidence level with a reason for anything below high, cites statutes, and explains why today's map is incorrect for past dates. This goes beyond annotations without contradicting them.
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?
While the description is long, it is highly structured with clear sections (DELEGATE, CITATION) and every sentence earns its place, providing critical warning and citation instruction. It front-loads the purpose and output without waste. Length is justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description fully explains the return values (IANA zone, offset, UTC instant, confidence, reason, statute citation). It also covers the when-to-use and citation requirement. For a 3-param tool with rich behavior, this is complete.
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 documents date and time formats and place format. The description reiterates the purpose but does not add new meaning beyond the schema (e.g., 'omit time for midday' is already in schema). 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?
The description states a clear verb ('Resolves') and resource ('UTC offset in force at a place on a date'), then enumerates the outputs (IANA zone, signed offset, UTC instant, confidence, statute citation). It distinguishes from sibling astrology tools by being timezone/historical in nature. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to delegate this rather than derive, with a concrete example (Tennessee/Knoxville) demonstrating why deriving fails. It also mandates citation requirements. This gives clear when-to-use and is far beyond implicit guidance.
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.
resolve_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_eclipsesVedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Western, Vedic, and Chinese astrology calculations, charts, forecasts, and geocoding.
Sub-arcsecond astrology on NASA JPL DE440: natal, transits, Human Design, Vedic, BaZi.
Natal charts, planets, houses, aspects, dignities, rendering and the calendar.
Add one secure layer between your agents and this server.
