Natal charts, transits, kundli, dashas, panchang, Gun Milan. JPL DE440, no LLM, hashed.
Scored across 16 tools
Most tools occupy clearly distinct niches (Western positions vs. natal vs. transits; Vedic kundli vs. panchang vs. dashas), and the descriptions make the hierarchy explicit. However, kundli is a strict subset of both kundli_full and vedic_report, and planet_positions/natal_chart/aspects overlap on positions and aspects, so an agent must read carefully to pick the cheapest sufficient tool.
Everything is snake_case and readable, with no camelCase or casing drift. The naming is mostly domain-noun based (kundli, panchang, doshas) with a few verb-led utility names (resolve_birth_time, verify_result_hash), a minor stylistic inconsistency but not confusing.
16 tools is at the upper edge of comfortable but justified by the breadth of two astrology systems plus utility/discovery tools. Each tool maps to a real domain operation (charts, dashas, doshas, matching, transits, time resolution, hash verification) rather than filler.
Coverage is strong: full Western (positions, natal, aspects, synastry, transits) and Vedic (panchang, kundli/full, nakshatras, dashas, doshas, gun_milan, report) surfaces plus time-resolution and verification utilities. Minor gaps remain, such as Western predictive tools (progressions, solar/planetary returns), which agents cannot cover with the current set.
Western astrology aspects: find the aspects between planets at a moment, or between longitudes you supply, with orb, exactness and applying or separating. Either give a moment (datetime, optional place) and get the aspects among all planets, or give 'longitudes' {name: degrees} and get the pure geometry. Orbs are explicit and overridable. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.02 per call via REST POST https://astro-agent.dev/v1/western/aspects (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Western convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | No | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | No | Decimal degrees, east positive. | |
| longitudes | No | Optional {name: degrees} or {name: {longitude, speed}}; when given, no ephemeris is used. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: deterministic JPL DE440 computation with no LLM, a meta.result_sha256 on every result, and the billing model ($0.02/call via REST with x402 or MPP, first 3 calls free) — cost and payment behavior an agent cannot infer from 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 core capability and the mode split are front-loaded in the first two sentences, and the remaining details (determinism, hash, pricing) are compact. The pricing/endpoint tail is somewhat dense but each clause carries actionable information, so little is 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?
An output schema exists, so return-value shape need not be explained. With 10 optional params, nested option objects, and two modes, the description supplies the missing operational context (mode selection, determinism, hash, cost) needed to invoke it correctly; only sibling routing is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 applies. The description adds meaning the schema does not: it establishes that 'longitudes' bypasses the ephemeris entirely ('pure geometry'), and that orbs are 'explicit and overridable', clarifying the relationship between the two input families and the options.orbs field.
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+resource ('find the aspects between planets') and immediately scopes it as Western astrology, which distinguishes it from the Vedic siblings (kundli, doshas, vimshottari_dasha). It also enumerates the two distinct operating modes (moment-based vs supplied longitudes), so an agent can tell exactly what the tool computes without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing between the two modes: 'Either give a moment (datetime, optional place) ... or give longitudes {name: degrees} and get the pure geometry.' That is strong internal usage guidance. It stops short of naming when to prefer a sibling (e.g. synastry for cross-chart aspects), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every astrology tool with its price, input schema and an example request. Free; call it first to pick the right tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| calls | Yes | The $0.01-0.02 tools: MCP tool name, price, REST route, what it computes and an example request (input schemas are in tools/list). |
| payment | No | Free calls, payment protocols (x402, MPP) and networks. |
| premium | Yes | The full-chart tools, same fields as 'calls'. |
| service | Yes | Service name. |
| support | No | Contact, documentation and policies. |
| tagline | No | One-line summary of the service. |
| discovery | No | Discovery documents: OpenAPI, MCP server card, A2A agent card. |
| start_here | No | Which tool to call first for common questions. |
| engine_version | No | Calculation engine version. |
| free_endpoints | No | Endpoints that are always free (catalog, verify, health). |
| why_use_this_instead_of_computing_it_yourself | No | Reasons to prefer these tools over computing a chart yourself. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is fully covered. The description adds the cost signal ("Free"), which annotations do not express, but its listing of returned fields largely duplicates the existing output schema rather than disclosing new behavior.
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?
Two short sentences, both front-loaded with the highest-value information (what you get, then when to call it). No filler or redundancy.
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?
A zero-parameter, read-only discovery tool with an output schema that already defines the return shape. The description gives the agent everything it needs to decide to call it and expect the catalog contents.
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?
Zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100%, and no invocation arguments need explanation.
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 (List) and resource (every astrology tool) and details what each entry contains: price, input schema, and example request. That is clearly distinguishable from all listed siblings, which are individual computation tools rather than a catalog.
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?
"Call it first to pick the right tool" gives explicit ordering guidance for tool selection, which is exactly the agent-facing decision this tool supports. It stops short of naming conditions where it should be skipped, but for a discovery entry point that is a minor omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology doshas: check Manglik (Kuja), Kaal Sarp and Sade Sati / Dhaiya, each with the rule applied and the relevant dates. Manglik from lagna, Moon and Venus with severity and commonly cited cancellations; Kaal Sarp with type and direction (partial cases flagged); Sade Sati cycles and Dhaiya phases with start/end dates over 100 years, plus the status on a given date. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.15 per call via REST POST https://astro-agent.dev/v1/vedic/doshas (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| on_date | No | YYYY-MM-DD (UTC): also report what is active on this date. | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds genuinely new context: deterministic computation via JPL DE440 with no LLM, a meta.result_sha256 on every result, partial Kaal Sarp cases flagged, and paid access ($0.15/call, first 3 free via x402/MPP). This is rich disclosure beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the three doshas and their outputs before the operational details. Dense and mostly waste-free, though the pricing/REST endpoint sentence is longer than needed purely for tool selection and pushes the line count up.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary; the description covers scope, determinism, hashing, partial-case handling, date coverage, and cost. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 10 params, so the schema already explains date/time/datetime alternatives, timezone resolution, ayanamsa, node_type, house_system, and ambiguous_time handling. The description only indirectly touches parameters (e.g. 'status on a given date' implying on_date), so it adds little beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (Vedic doshas) and enumerates exactly which ones it computes (Manglik/Kuja, Kaal Sarp, Sade Sati/Dhaiya), with the rule applied and dates. This clearly separates it from siblings like kundli, gun_milan, or vimshottari_dasha, which cover different computations.
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 strong context for when this tool applies (dosha-specific analysis, status on a given date, 100-year date ranges) and notes the price and free-call allowance. It stops short of explicitly naming alternatives such as kundli_full or vedic_report or stating when NOT to use this tool, so it is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology kundli matching (horoscope matching, marriage compatibility): 36-point Ashtakoota Gun Milan with all 8 kootas and reasons, plus dosha and Manglik checks. Varna, Vashya, Tara, Yoni, Graha Maitri, Gana, Bhakoot and Nadi scored from both Moons, each with the attributes and rule behind the score, Nadi/Bhakoot dosha flags with commonly cited cancellations, and both partners' Manglik status. Boy = person_a, girl = person_b by convention. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.25 per call via REST POST https://astro-agent.dev/v1/vedic/gun-milan (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| person_a | Yes | Groom / boy (traditional convention). | |
| person_b | Yes | Bride / girl. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new operational context — determinism (JPL DE440, no LLM), a per-result meta.result_sha256 for verification, and the pricing/transport model ($0.25 per call, first 3 free) which shapes how an agent should call it. It stops short of describing latency, rate limits, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph with the core capability front-loaded (matching → 8 kootas → dosha/Manglik → convention → determinism/hash → price), so an agent gets the essentials immediately. It loses a point for trailing commercial detail ('your first 3 calls are free here') and listing all eight koota names, which is more inventory than an invocation decision needs.
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 two-person, deeply nested input with an output schema present, the description covers the result shape at a summary level (8 kootas with attributes/rules, dosha cancellation flags, Manglik status) and the verification hook, so nothing essential is missing. It does not need to restate return values because an output schema exists.
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 nested person_a/person_b fields are already well documented, including the boy/groom and bride/girl labels, so the description's 'Boy = person_a, girl = person_b' mapping is largely redundant. The description adds no extra meaning about the options object or time-handling parameters beyond what the schema states.
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?
Names a specific verb+resource ('Vedic astrology kundli matching... 36-point Ashtakoota Gun Milan') and enumerates exactly what it computes (all 8 kootas with reasons, dosha/Manglik checks). This is specific enough that an agent can separate it from the generic kundli/natal_chart siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the domain framing ('horoscope matching, marriage compatibility') and the convention note 'Boy = person_a, girl = person_b', but there is no explicit when-to-use clause and no sibling is named as the alternative for narrower jobs (e.g. doshas, synastry). The agent must infer routing from the purpose text alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology birth chart (kundli, Jyotish horoscope, D1 and D9): lagna and the nine grahas with rashi, nakshatra, pada, house, dignity and combustion. The Jyotish birth chart: ayanamsa (Lahiri default; Raman, KP, Yukteshwar, Fagan-Bradley, True Chitrapaksha), lagna, grahas with rashi, nakshatra/pada/lord, bhava, dignity (exalted, debilitated, moolatrikona, own sign), retrograde and combustion, house table with lords and occupants, and the Navamsa (D9). Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.15 per call via REST POST https://astro-agent.dev/v1/vedic/kundli (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine value beyond them: deterministic computation (JPL DE440, no LLM), a per-result integrity hash (meta.result_sha256), a $0.15 per-call price, and the REST endpoint with x402/MPP payment. It stops short of describing failure modes (e.g. what happens on out-of-range coordinates or ambiguous dates) or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, which is good, but the middle is repetitive: the chart contents (lagna, grahas, rashi, nakshatra/pada, dignity) are listed twice in near-identical phrasing. Large chunks of the text describe return values that an existing output schema already covers, so several sentences do not fully earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema, the extensive enumeration of returned fields is unnecessary, while the genuinely useful missing piece — how this differs from kundli_full — is absent. A 9-parameter tool at 100% schema coverage leaves the description only moderate work to do, and it does not do the routing part of it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter, enum and default is already documented in the schema, so the description need not carry this burden. The ayanamsa list in the prose is largely redundant with the schema enum, though it does mildly reinforce that Lahiri is the default convention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (compute a Vedic birth chart / kundli) and enumerates the artifacts (lagna, nine grahas, rashi, nakshatra, pada, house, dignity, combustion, navamsa). However, it never distinguishes itself from the near-identically named sibling 'kundli_full', nor from natal_chart or vedic_report, so an agent cannot route between them from this text alone.
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?
No when-to-use or when-not-to-use guidance is given. With 16 siblings including kundli_full, natal_chart, vedic_report and panchang, the absence of any routing rule is a real gap. Commercial details (price, first 3 free) are present but that is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology full kundli: all 16 Shodashavarga divisional charts, D1 to D60 (navamsa, dasamsa...), by Parashara's rules. Everything in /vedic/kundli plus D1, D2, D3, D4, D7, D9, D10, D12, D16, D20, D24, D27, D30, D40, D45 and D60, each with its lagna, placements and house table. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.32 per call via REST POST https://astro-agent.dev/v1/vedic/kundli-full (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered and the description correctly adds non-obvious traits instead: deterministic computation (JPL DE440, no LLM), a verifiable meta.result_sha256 on every result, and the $0.32-per-call paid model behind x402/MPP. That is real invocation-relevant context (cost/payment/auth) beyond the structured fields. It does not discuss failure modes (e.g. what happens with unknown birth time beyond the schema note), so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The paragraph is front-loaded with the deliverable (16 vargas, D-list) before the computation and pricing details, and every clause carries information. The closing price/endpoint/free-tier sentence is commercial but genuinely relevant to invocation. Slightly dense and list-heavy rather than wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with a full output schema and complete annotations, the description supplies what structured fields cannot: the exact chart set returned, determinism/reproducibility guarantees, cost and payment channel. The relative positioning versus the sibling 'kundli' is implied rather than spelled out, but nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters carry schema descriptions (100% coverage), including enums, defaults and the date/time vs datetime alternatives, so the description need not repeat them. The description adds only the scope claim ('everything in /vedic/kundli plus...') and no parameter-level meaning. Baseline 3 applies when the schema does the heavy lifting.
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/resource ('Vedic astrology full kundli') and enumerates exactly what is produced: all 16 Shodashavarga charts D1–D60, each with lagna, placements and house table. It also differentiates from the sibling 'kundli' by stating it contains 'everything in /vedic/kundli plus' the divisional charts, so an agent can pick between them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for selection: use this when you need the full 16-varga set rather than the base kundli, since it is a superset of /vedic/kundli. It also flags the invocation channel (REST POST endpoint, x402/MPP payment, first 3 calls free). It stops short of an explicit 'do not use this if you only need D1' exclusion, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology nakshatras: the sidereal nakshatra, pada and lord of every graha, plus the janma nakshatra with gana, yoni, nadi and varna. The 27 lunar mansions for each of the 9 grahas at a moment (Lahiri by default, 6 ayanamsas), with the birth star's attributes used in matching. Or pass 'longitude_sidereal' for a direct lookup. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.02 per call via REST POST https://astro-agent.dev/v1/vedic/nakshatra (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | No | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | No | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| longitude_sidereal | No | Optional direct lookup, degrees 0-360. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds substantial behavior beyond them: deterministic JPL DE440 computation with no LLM, a result_sha256 for verification, timezone/historical-offset resolution, and a pricing/transport model ($0.02 via REST POST, x402 or MPP, first 3 calls free). These are exactly the operational facts an agent needs and cannot get from 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?
Front-loaded with what the tool computes, followed by defaults, determinism and pricing. It is dense and condensed into one long paragraph with heavy parentheticals, and the pricing/endpoint sentence is more sales than semantics, but nearly every clause carries 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?
With an output schema present, return values need not be explained, and 10 parameters are fully schema-documented. The description adds determinism, hash, timezone resolution and the direct-lookup path, which is enough for correct invocation; the only soft spot is that the interaction between datetime+coords and longitude_sidereal (when each is expected) is only implied.
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% (ayanamsa default, node_type, house_system, time_basis, ambiguous_time, lat/long all documented in-schema), so baseline is 3. The description reinforces the ayanamsa set and, usefully, explains that longitude_sidereal is a direct-lookup path that bypasses the date/place route — a semantic addition, but not enough to lift beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: it returns the sidereal nakshatra, pada and lord for each of the 9 grahas, plus the janma nakshatra attributes (gana, yoni, nadi, varna). It also names the scope (27 lunar mansions, Lahiri default, 6 ayanamsas) and an alternate input mode (longitude_sidereal), so an agent can distinguish it from kundli/planet_positions without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use — nakshatra data at a moment, and the birth star's attributes 'used in matching' — and routes the agent to an alternate mode when it has a sidereal longitude instead of a date/place. It stops short of naming sibling tools (gun_milan, kundli, planet_positions) or stating when NOT to use it, so no explicit alternatives comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Western astrology natal chart (birth chart, horoscope): planets in zodiac signs and houses, sun sign, moon sign and rising sign (ascendant), MC, aspects and a summary. Everything a natal reading needs, computed exactly: positions, house cusps (Placidus by default; Koch, Whole Sign, Equal, Porphyry, Regiomontanus, Campanus, Topocentric, Alcabitius, Morinus, Meridian), ascendant/MC/DSC/IC, aspects with orbs and applying/separating state, element and modality balance, chart ruler, sect and Part of Fortune. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.06 per call via REST POST https://astro-agent.dev/v1/western/natal (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Western convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely useful behavior beyond them: determinism via JPL DE440 with no LLM, a meta.result_sha256 for verification, and a $0.06/call price with x402/MPP payment and a free tier. These are things an agent needs but cannot get from 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?
It is front-loaded with a clear purpose sentence, but the second sentence is a very long enumerated feature list and the closing sentence packs in pricing, endpoint, and payment protocols. Some of the feature enumeration is marketing padding rather than selection-relevant 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?
With an output schema present, the description needn't explain return values, and it adds operational context (determinism, hash, pricing). The only gap is routing guidance versus sibling chart tools, which slightly limits completeness for an agent choosing among many astrology endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters including enums and defaults. The description restates house systems and aspect/orb behavior but adds no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: computes a Western astrology natal chart, and enumerates the exact outputs (planets in signs/houses, sun/moon/rising, MC, aspects). This clearly distinguishes it from Vedic siblings like kundli or specialized tools like planet_positions and aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Everything a natal reading needs') but never states when to choose this over siblings such as planet_positions, aspects, or the Vedic kundli family, nor any preconditions. Usage must be inferred from the tool name and output list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology panchang (Hindu calendar) for a day and place: tithi, vara, nakshatra, yoga and karana with their exact end times, plus sunrise and sunset. The Hindu almanac for any moment and place: the five limbs with their end times (to the minute), paksha, Moon and Sun rashi, sunrise/sunset, and the vara by the sunrise-to-sunrise rule. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.02 per call via REST POST https://astro-agent.dev/v1/vedic/panchang (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe/idempotent profile, and the description goes well beyond them: deterministic computation (JPL DE440, no LLM), a verifiable meta.result_sha256 on every result, per-call pricing ($0.02), the payment mechanisms (x402 or MPP), and a free-call allowance. These are exactly the operational facts an agent needs before invoking a paid external call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and the sentences are dense, but the output list is effectively stated twice ('tithi, vara, nakshatra, yoga and karana... plus sunrise and sunset' then 'the five limbs with their end times... sunrise/sunset'), which is wasted space. Otherwise efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with nested options and an output schema, the description supplies the operational context the structured fields cannot: cost, payment path, determinism guarantee, and result-hash verification. Return values need not be explained since an output schema exists, so nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter (datetime, timezone, time_basis, ambiguous_time, nested options) is fully documented in the schema. The description's detail about tithi/paksha/rashi describes return values rather than adding meaning to any parameter. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'Vedic astrology panchang (Hindu calendar) for a day and place' and enumerates the computed limbs (tithi, vara, nakshatra, yoga, karana, sunrise/sunset). An agent can tell this is a day-and-place almanac, distinct from natal_chart or kundli. It never names a sibling to contrast with, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the scope ('for a day and place', 'for any moment and place'); there is no explicit when-to-use-this-vs-kundli/transits guidance or any exclusion. The only decision guidance is commercial (first 3 calls free, $0.02 after), not functional. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Western astrology planet positions: the zodiac sign, longitude, latitude, speed and retrograde flag of the Sun, Moon, planets, lunar nodes and Lilith at any moment. Geocentric apparent positions from NASA/JPL DE440 for any moment 1800-2200, with sign, degree, element, modality, daily speed and retrograde status. Location is optional (only used to interpret a local time). Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.01 per call via REST POST https://astro-agent.dev/v1/western/positions (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| options | No | Optional calculation settings; every default is the common Western convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | No | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | No | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only declare readOnly, idempotent, non-open-world). It discloses determinism and provenance (JPL DE440, no LLM), a hash verification field (meta.result_sha256), pricing ($0.01/call), the transport and endpoint, payment protocols, and a free-tier offer. These are exactly the operational facts an agent needs and are not derivable from annotations or 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?
Four sentences, front-loaded with what the tool returns, then data source and provenance, then the optional-location clarification, then operational details. Every clause adds information; nothing is redundant with the schema or annotations.
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?
Given the tool has 9 parameters, nested options, an output schema, and rich annotations, the description covers the remaining gaps: data provenance, determinism, verification, and cost. With an output schema present, return structure need not be explained. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter fully, including defaults and enums. The description adds a useful high-level note that location is optional, but otherwise the 'options', 'datetime', 'time_basis', etc. semantics come from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Western astrology planet positions: the zodiac sign, longitude, latitude, speed and retrograde flag...'. It enumerates the exact celestial bodies covered and explicitly frames itself as Western astrology, which distinguishes it from the Vedic-leaning siblings (kundli, nakshatras, panchang, etc.). An agent can distinguish this from natal_chart or transits based on the Western-geocentric-planetary-position scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the use case ('at any moment', date range 1800-2200, geocentric apparent positions) and notes that location is optional and only used to interpret local time. However, it does not explicitly contrast with siblings like natal_chart (which also produces planetary positions) or transits, so an agent comparing tool choices gets no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Astrology birth time to UTC conversion: convert a local birth date, time and place into exact Universal Time, with the historical time zone and UTC offset, Delta T, Local Mean Time and true solar time. The step LLMs most often get wrong. Resolves the IANA time zone from coordinates, applies the offset in force on that date (historical DST, Local Mean Time before standard time), flags ambiguous or non-existent local times instead of guessing, and returns Julian Days (UT/TT), Delta T, Local Mean Time, true (apparent) solar time and the equation of time. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.01 per call via REST POST https://astro-agent.dev/v1/time/resolve (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | No | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | No | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: declares determinism (JPL DE440, no LLM), a verifiable meta.result_sha256, ambiguity handling that flags rather than guesses, historical DST/LMT rules, and the pricing/auth model ($0.01 per call, x402 or MPP, first 3 free, REST endpoint). This is exactly the extra context an agent needs and annotations do not carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose well, but the return values are enumerated twice ('with the historical time zone and UTC offset, Delta T, Local Mean Time and true solar time' then 'returns Julian Days (UT/TT), Delta T, Local Mean Time, true (apparent) solar time and the equation of time') and an output schema already exists. The pricing/endpoint sentence is useful but tacked on.
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 an 8-parameter tool with tricky historical-timezone edge cases, the description covers input semantics, ambiguity policy, determinism, verification, and commercial access. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented, and the description adds no syntax or format detail beyond it. It does explain the ambiguous/non-existent time policy and coordinate-based timezone resolution, which lightly frames ambiguous_time and timezone, but the baseline 3 applies when the schema does the heavy lifting.
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 up front ('Astrology birth time to UTC conversion: convert a local birth date, time and place into exact Universal Time') and enumerates the outputs. It is unmistakably distinct from siblings like natal_chart, kundli, or verify_result_hash.
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?
Positions the tool as 'The step LLMs most often get wrong', which implies it is the preprocessing step before chart work, and notes the fallback behaviour when time is unknown. It never names an alternative sibling or states when NOT to use it, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Western astrology synastry (relationship compatibility): compare two birth charts with cross-aspects, house overlays both ways and composite midpoints. Two natal charts compared: every cross-aspect with orbs, where each person's planets fall in the other's houses, harmonious/challenging counts, and composite (midpoint) positions and angles. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.12 per call via REST POST https://astro-agent.dev/v1/western/synastry (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Optional calculation settings; every default is the common Western convention. | |
| person_a | Yes | First person's birth data. | |
| person_b | Yes | Second person's birth data. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context on top: deterministic computation (JPL DE440, no LLM), verifiability via meta.result_sha256, cost of $0.12 per call, payment mechanisms (x402 or MPP), and a free tier of three calls. That is well beyond what the structured fields provide, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and efficient despite being dense; pricing and determinism details earn their place. There is mild redundancy between the first sentence's 'cross-aspects, house overlays both ways and composite midpoints' and the second sentence's fuller restatement of the same outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description still adds determinism, hashing, and cost context appropriate for a paid, nested-parameter tool. The only missing piece is guidance on when to choose this over adjacent aspect/chart tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter and enum thoroughly, giving a baseline of 3. The description restates concepts (orbs, house overlays, midpoints) but adds no syntax or constraint detail not already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('compare two birth charts' for synastry relationship compatibility) and enumerates the computed artifacts: cross-aspects with orbs, bidirectional house overlays, and composite midpoints. It is clearly distinct from a single-chart tool like natal_chart or aspects by construction, though it never names a sibling to route against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the domain framing ('relationship compatibility', 'Western astrology'), which separates it from the Vedic siblings like kundli or gun_milan, plus access logistics (price, free calls, REST endpoint). There is no explicit when-to-use/when-not statement or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Western astrology transits: the transits to a natal chart at a moment, and the exact dates transiting aspects perfect over a window of up to a year. 'transit': aspects from the sky at a moment to every natal point, with the natal house each transiting planet occupies. 'window': the exact UTC minute every transiting planet perfects each aspect to each natal point over up to 366 days (62 with the Moon), retrograde passes included. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.08 per call via REST POST https://astro-agent.dev/v1/western/transits (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| natal | Yes | Birth data. | |
| window | No | UTC dates YYYY-MM-DD, at most 366 days apart. | |
| options | No | Optional calculation settings; every default is the common Western convention. | |
| transit | No | The transit moment. A bare local time is read in the natal place's zone. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond annotations: determinism via JPL DE440, no LLM involvement, inclusion of retrograde passes in window mode, the 62-day Moon limit, and the meta.result_sha256 hash in every result. It also discloses pricing ($0.08/call, first 3 free) and auth methods (x402 or MPP), which are crucial operational details not covered by the readOnly/idempotent 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 dense but well-structured, front-loading the tool's purpose and then detailing each mode and technical guarantees. Every sentence carries information, though it could be slightly tighter by merging the pricing and determinism statements without losing clarity.
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?
Given the tool's complexity — nested parameters, two modes, output hash — the description covers all critical aspects: what each mode does, temporal limits, determinism, output integrity via hash, pricing, and authentication. With a rich output schema already present, no essential information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameter groups thoroughly. The description mentions modes ('transit' vs 'window') and the Moon limitation, which links to the window.include_moon parameter, but does not add syntax or format details beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 specifies a precise verb+resource — computing transits to a natal chart, with two clearly named modes ('transit' and 'window') — and explains what each mode returns. It distinguishes itself from sibling tools like natal_chart and synastry by emphasizing transits over time, not just a static chart or relationship comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use 'transit' (aspects at one moment) vs 'window' (exact timing over up to a year), giving context for mode selection. It does not explicitly exclude or contrast with other siblings like aspects or planet_positions, so a minor gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology report in one call: kundli, Vimshottari dashas, doshas and the birth panchang. The full Jyotish dossier for one person in a single deterministic call: everything in /vedic/kundli, /vedic/dashas (2 levels, running periods with on_date), /vedic/doshas and the panchang at birth. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.50 per call via REST POST https://astro-agent.dev/v1/vedic/report (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| on_date | No | YYYY-MM-DD (UTC): also report what is active on this date. | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial beyond-schema context: JPL DE440 determinism with no LLM, a per-result meta.result_sha256, the REST endpoint with x402/MPP payment, a $0.50 price and a 3-free-call allowance. These are exactly the operational traits an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the identity and contents, then the deterministic/sha256 trait, then pricing and endpoint. Dense but every clause earns its place; the endpoint URL is slightly heavy inline but is actionable 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?
An output schema exists so return values needn't be explained, and annotations cover the safety profile. The description completes the picture with determinism, hash verifiability (tying to the verify_result_hash sibling), payment model and cost, so an agent has everything needed to decide and invoke.
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 every parameter is already documented in the schema; baseline is 3. The description adds only minor semantic color by noting dashas return "2 levels, running periods with on_date," which lightly clarifies depth and the on_date parameter but does not go beyond the schema's own wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Vedic astrology report in one call") and enumerates the exact contents: kundli, Vimshottari dashas, doshas and birth panchang. This distinguishes it from siblings like kundli, vimshottari_dasha and doshas by positioning it as the aggregate one-call product.
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 phrase "The full Jyotish dossier for one person in a single deterministic call" makes clear this is the consolidation option versus calling the individual /vedic/kundli, /vedic/dashas and /vedic/doshas tools. However, it never explicitly names those sibling tools as the alternative or states when-not to use this, leaving that routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that an astrology result was not altered: recompute the SHA-256 of a 'result' object returned by any tool and compare it with the result_sha256 you hold. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | The 'result' object exactly as a tool returned it. | |
| result_sha256 | No | The meta.result_sha256 returned with it (64 hex characters). Omit to only recompute the hash. |
| Name | Required | Description |
|---|---|---|
| matches | No | Whether it equals the result_sha256 you sent. Absent if you sent none. |
| result_sha256 | Yes | SHA-256 recomputed from the 'result' you sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the operation is a pure recompute-and-compare, and it discloses the cost trait ('Free'). It does not describe mismatch handling, though the output schema exists to carry that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence carrying purpose, inputs, and the verification semantics, followed by a single-word cost note. Nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description fully covers the input contract and the meaning of the operation. Only minor gaps remain around how a mismatch is surfaced, which the output schema presumably handles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, including the omit-to-only-recompute behavior. The description reinforces that result_sha256 is the value 'you hold' (from meta), which is mildly additive but largely restates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Verify that an astrology result was not altered') and explains the exact mechanism: recompute the SHA-256 of a 'result' object and compare it to a held result_sha256. This clearly separates it from every sibling tool, which all compute astrology data rather than verify integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear condition for use ('the result_sha256 you hold') and implicitly scopes it to results returned by any tool in this server. It stops short of explicit when-not guidance (e.g. that it is unnecessary if no hash was retained), but the trigger condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic astrology dasha periods: the Vimshottari maha, antar and pratyantar dashas with exact dates, the balance at birth and the periods running now. The 120-year Vimshottari sequence from the Moon's exact nakshatra position: balance at birth, all 9 mahadashas with sub-periods down to 4 levels, and (with on_date) the periods running on a date. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.10 per call via REST POST https://astro-agent.dev/v1/vedic/dashas (x402 or MPP); your first 3 calls are free here.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (use with 'time' instead of 'datetime'). | |
| time | No | HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning). | |
| on_date | No | YYYY-MM-DD (UTC): also report what is active on this date. | |
| options | No | Optional calculation settings; every default is the common Parashari convention. | |
| datetime | No | Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'. | |
| latitude | Yes | Decimal degrees, north positive. | |
| timezone | No | IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date. | |
| longitude | Yes | Decimal degrees, east positive. | |
| time_basis | No | What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time. | civil |
| ambiguous_time | No | Which occurrence to use when a local time happens twice (DST fall-back). | earlier |
| Name | Required | Description |
|---|---|---|
| meta | Yes | Provenance of the result. |
| result | Yes | The calculation result. |
| endpoint | Yes | The REST route that computed it, e.g. 'western/natal'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial extra context: deterministic JPL DE440 computation with no LLM, a meta.result_sha256 on every result, and pricing/auth ($0.10 per call, x402 or MPP, first 3 free) via the REST endpoint. These are real behavioral facts an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose and scoped outputs before the operational/pricing details. It repeats 'balance at birth' and the 120-year sequence idea, which is mild redundancy, but overall it is dense and earns most of its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with a full output schema present, the description covers purpose, output breadth, determinism, cost, and the hash for verification. The one notable gap is the absence of sibling routing (e.g., versus kundli or panchang), which would make selection fully unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters including depth, ayanamsa, and node_type. The description only adds framing ('sub-periods down to 4 levels', periods running on a date) that largely restates schema semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: it names Vedic Vimshottari dasha periods, the maha/antar/pratyantar levels, exact dates, balance at birth, and currently-running periods. An agent can distinguish this from siblings like kundli, panchang, or nakshatras without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage conditions — 'the periods running now' and '(with on_date) the periods running on a date' — but never names an alternative tool or states when to prefer this over kundli_full or natal_chart. Usage is inferable rather than explicit.
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.
astro_catalog1 field changedOutput schema / properties / calls / descriptionPrevious value: -"The $0.01-0.02 tools: name, price, REST route, input schema and an example request."New value: +"The $0.01-0.02 tools: MCP tool name, price, REST route, what it computes and an example request (input schemas are in tools/list)."aspects1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "aspects": {
+ "description": "Aspects between two points: point_a, point_b, aspect name, exact angle, orb, allowed orb, exactness percentage and whether it is applying or separating.",
+ "type": "array"
+ },
+ "settings": {
+ "description": "The aspect set and orbs applied, and where the longitudes came from.",
+ "type": "object"
+ }
+ },
+ "required": [
+ "settings",
+ "aspects"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}astro_catalog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calls": {
+ "description": "The $0.01-0.02 tools: name, price, REST route, input schema and an example request.",
+ "type": "array"
+ },
+ "discovery": {
+ "description": "Discovery documents: OpenAPI, MCP server card, A2A agent card.",
+ "type": "object"
+ },
+ "engine_version": {
+ "description": "Calculation engine version.",
+ "type": "string"
+ },
+ "free_endpoints": {
+ "description": "Endpoints that are always free (catalog, verify, health).",
+ "type": "object"
+ },
+ "payment": {
+ "description": "Free calls, payment protocols (x402, MPP) and networks.",
+ "type": "object"
+ },
+ "premium": {
+ "description": "The full-chart tools, same fields as 'calls'.",
+ "type": "array"
+ },
+ "service": {
+ "description": "Service name.",
+ "type": "string"
+ },
+ "start_here": {
+ "description": "Which tool to call first for common questions.",
+ "type": "string"
+ },
+ "support": {
+ "description": "Contact, documentation and policies.",
+ "type": "object"
+ },
+ "tagline": {
+ "description": "One-line summary of the service.",
+ "type": "string"
+ },
+ "why_use_this_instead_of_computing_it_yourself": {
+ "description": "Reasons to prefer these tools over computing a chart yourself.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "service",
+ "calls",
+ "premium"
+ ],
+ "type": "object"
+}doshas1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "doshas": {
+ "description": "Manglik (Kuja), Kaal Sarp and Sade Sati / Dhaiya, each with whether it applies, the rule used and the relevant dates.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: sidereal zodiac, ayanamsa (name and value in degrees), lunar node type, house system and divisional-chart rules.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "doshas"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}gun_milan1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "doshas": {
+ "description": "Matching doshas such as Bhakoot dosha, with whether each applies and is cancelled.",
+ "type": "object"
+ },
+ "kootas": {
+ "description": "The eight kootas (varna, vashya, tara, yoni, graha_maitri, gana, bhakoot, nadi), each with points scored, maximum and the reason.",
+ "type": "object"
+ },
+ "manglik": {
+ "description": "Manglik status of each person and whether the pair matches on it.",
+ "type": "object"
+ },
+ "max": {
+ "description": "Maximum possible score (36).",
+ "type": "integer"
+ },
+ "person_a": {
+ "description": "First person: subject and natal Moon (rashi, nakshatra, pada).",
+ "type": "object"
+ },
+ "person_b": {
+ "description": "Second person: subject and natal Moon (rashi, nakshatra, pada).",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied, plus the Ashtakoota ruleset and convention used.",
+ "type": "object"
+ },
+ "total": {
+ "description": "Total Gun Milan score, out of 'max'.",
+ "type": "number"
+ },
+ "verdict": {
+ "description": "Plain-language reading of the total score.",
+ "type": "string"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "settings",
+ "person_a",
+ "person_b",
+ "kootas",
+ "total",
+ "max",
+ "verdict",
+ "doshas",
+ "manglik"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}kundli1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "bhavas": {
+ "description": "The twelve houses (bhavas): sign, rashi, lord and the grahas occupying each one.",
+ "type": "array"
+ },
+ "grahas": {
+ "description": "The nine grahas (Sun to Ketu): sidereal longitude, rashi, sign lord, nakshatra, pada, nakshatra lord, deity, house, and dignity flags.",
+ "type": "array"
+ },
+ "lagna": {
+ "description": "The ascendant (lagna): sidereal longitude, rashi and sign, degree, sign lord, nakshatra, pada and nakshatra lord.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: sidereal zodiac, ayanamsa (name and value in degrees), lunar node type, house system and divisional-chart rules.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "summary": {
+ "description": "Key facts: lagna sign and lord, Moon sign, sidereal Sun sign, janma nakshatra with pada and lord, and the exalted, debilitated, retrograde and combust grahas.",
+ "type": "object"
+ },
+ "vargas": {
+ "description": "Divisional charts D1 (rashi) and D9 (navamsa), keyed by name.",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "lagna",
+ "grahas",
+ "bhavas",
+ "summary",
+ "vargas"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}kundli_full1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "bhavas": {
+ "description": "The twelve houses (bhavas): sign, rashi, lord and the grahas occupying each one.",
+ "type": "array"
+ },
+ "grahas": {
+ "description": "The nine grahas (Sun to Ketu): sidereal longitude, rashi, sign lord, nakshatra, pada, nakshatra lord, deity, house, and dignity flags.",
+ "type": "array"
+ },
+ "lagna": {
+ "description": "The ascendant (lagna): sidereal longitude, rashi and sign, degree, sign lord, nakshatra, pada and nakshatra lord.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: sidereal zodiac, ayanamsa (name and value in degrees), lunar node type, house system and divisional-chart rules.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "summary": {
+ "description": "Key facts: lagna sign and lord, Moon sign, sidereal Sun sign, janma nakshatra with pada and lord, and the exalted, debilitated, retrograde and combust grahas.",
+ "type": "object"
+ },
+ "vargas": {
+ "description": "All 16 Shodashavarga divisional charts, D1 to D60, keyed by name (D1, D2, D3, D4, D7, D9, D10, D12, D16, D20, D24, D27, D30, D40, D45, D60).",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "lagna",
+ "grahas",
+ "bhavas",
+ "summary",
+ "vargas"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}nakshatras1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "grahas": {
+ "description": "Nakshatra and pada of each of the nine grahas, with lord and deity.",
+ "type": "array"
+ },
+ "janma_nakshatra": {
+ "description": "The Moon's (birth) nakshatra: name, index, pada, lord, deity and fraction elapsed.",
+ "type": "object"
+ },
+ "janma_nakshatra_attributes": {
+ "description": "Yoni, gana, nadi and lord of the birth nakshatra.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: sidereal zodiac, ayanamsa and lunar node type.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "janma_nakshatra",
+ "janma_nakshatra_attributes",
+ "grahas"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}natal_chart1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "angles": {
+ "description": "Ascendant, midheaven, descendant and imum coeli, each with longitude and sign.",
+ "type": "object"
+ },
+ "aspects": {
+ "description": "Aspects between two points: point_a, point_b, aspect name, exact angle, orb, allowed orb, exactness percentage and whether it is applying or separating.",
+ "type": "array"
+ },
+ "houses": {
+ "description": "The twelve house cusps: longitude, sign, degree in sign, element and modality.",
+ "type": "array"
+ },
+ "points": {
+ "description": "One entry per body or point (Sun to Pluto, lunar nodes, Chiron...): ecliptic longitude, sign, degree in sign, element, modality, latitude, daily speed, retrograde flag, distance in AU and, with a location, the house.",
+ "type": "array"
+ },
+ "settings": {
+ "description": "Settings applied: zodiac, house system and the aspect set with its orbs.",
+ "type": "object"
+ },
+ "sidereal_time": {
+ "description": "Local sidereal time as ARMC (degrees) and the true obliquity of the ecliptic.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "summary": {
+ "description": "Key facts: Sun, Moon and rising signs, element and modality balance, retrograde planets, chart ruler, day or night chart (sect) and the Part of Fortune.",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "angles",
+ "houses",
+ "sidereal_time",
+ "points",
+ "aspects",
+ "summary"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}panchang1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "panchang": {
+ "description": "The five limbs: tithi, nakshatra, yoga, karana and vara (weekday), plus Sun and Moon positions, Moon phase angle, ayanamsa, sunrise and sunset.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "panchang"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}planet_positions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "points": {
+ "description": "One entry per body or point (Sun to Pluto, lunar nodes, Chiron...): ecliptic longitude, sign, degree in sign, element, modality, latitude, daily speed, retrograde flag, distance in AU and, with a location, the house.",
+ "type": "array"
+ },
+ "settings": {
+ "description": "Settings applied (zodiac).",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "points"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}resolve_birth_time1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "location": {
+ "description": "The latitude and longitude used, in decimal degrees.",
+ "type": "object"
+ },
+ "time": {
+ "description": "Resolved time: local input, IANA time zone and how it was found, historical UTC offset, DST flag, UTC instant, Julian days (UT and TT), Delta T, local mean time, true solar time and the equation of time.",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "time",
+ "location"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}synastry1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "aspect_counts": {
+ "description": "Number of harmonious, challenging and conjunction cross-aspects.",
+ "type": "object"
+ },
+ "composite_midpoints": {
+ "description": "Composite chart by midpoints: points, angles and the method used.",
+ "type": "object"
+ },
+ "cross_aspects": {
+ "description": "Aspects between a point of person A and a point of person B, with orb and exactness.",
+ "type": "array"
+ },
+ "house_overlays": {
+ "description": "Which house of the other chart each person's points fall in.",
+ "type": "object"
+ },
+ "person_a": {
+ "description": "First person's chart: subject, points and angles.",
+ "type": "object"
+ },
+ "person_b": {
+ "description": "Second person's chart: subject, points and angles.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: zodiac, house system and the aspect set with its orbs.",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "person_a",
+ "person_b",
+ "settings",
+ "cross_aspects",
+ "aspect_counts",
+ "house_overlays",
+ "composite_midpoints"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}transits1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "natal": {
+ "description": "The natal chart the transits are measured against: subject, settings, points and angles.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "The aspect set and orbs applied.",
+ "type": "object"
+ },
+ "transit": {
+ "description": "The transit moment: its time, the transiting points and their aspects to the natal chart.",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ },
+ "window": {
+ "description": "Exact transit hits over the requested window: start, end, whether the Moon is included, precision, count and the list of hits with their exact dates.",
+ "type": "object"
+ }
+ },
+ "required": [
+ "natal",
+ "settings",
+ "transit",
+ "window"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}vedic_report1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "bhavas": {
+ "description": "The twelve houses (bhavas): sign, rashi, lord and the grahas occupying each one.",
+ "type": "array"
+ },
+ "dasha": {
+ "description": "Vimshottari dasha: system, year length, depth, balance at birth, the mahadashas with their antar and pratyantar periods and exact dates, and the periods running now ('current').",
+ "type": "object"
+ },
+ "doshas": {
+ "description": "Manglik (Kuja), Kaal Sarp and Sade Sati / Dhaiya, each with whether it applies, the rule used and the relevant dates.",
+ "type": "object"
+ },
+ "grahas": {
+ "description": "The nine grahas (Sun to Ketu): sidereal longitude, rashi, sign lord, nakshatra, pada, nakshatra lord, deity, house, and dignity flags.",
+ "type": "array"
+ },
+ "janma_panchang": {
+ "description": "The panchang at birth: tithi, nakshatra, yoga, karana and vara.",
+ "type": "object"
+ },
+ "lagna": {
+ "description": "The ascendant (lagna): sidereal longitude, rashi and sign, degree, sign lord, nakshatra, pada and nakshatra lord.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: sidereal zodiac, ayanamsa (name and value in degrees), lunar node type, house system and divisional-chart rules.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "summary": {
+ "description": "Key facts: lagna sign and lord, Moon sign, sidereal Sun sign, janma nakshatra with pada and lord, and the exalted, debilitated, retrograde and combust grahas.",
+ "type": "object"
+ },
+ "vargas": {
+ "description": "Divisional charts D1 (rashi) and D9 (navamsa), keyed by name.",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "lagna",
+ "grahas",
+ "bhavas",
+ "summary",
+ "vargas",
+ "dasha",
+ "doshas",
+ "janma_panchang"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}verify_result_hash1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "matches": {
+ "description": "Whether it equals the result_sha256 you sent. Absent if you sent none.",
+ "type": "boolean"
+ },
+ "result_sha256": {
+ "description": "SHA-256 recomputed from the 'result' you sent.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result_sha256"
+ ],
+ "type": "object"
+}vimshottari_dasha1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endpoint": {
+ "description": "The REST route that computed it, e.g. 'western/natal'.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Provenance of the result.",
+ "properties": {
+ "astronomy_library": {
+ "description": "Astronomy library and version.",
+ "type": "string"
+ },
+ "compute_ms": {
+ "description": "Computation time in milliseconds.",
+ "type": "number"
+ },
+ "computed_at": {
+ "description": "When it was computed (UTC, ISO 8601).",
+ "type": "string"
+ },
+ "deterministic": {
+ "description": "Always true: same input, same result.",
+ "type": "boolean"
+ },
+ "engine": {
+ "description": "Engine name and version.",
+ "type": "string"
+ },
+ "ephemeris": {
+ "description": "Ephemeris used (NASA/JPL DE440).",
+ "type": "string"
+ },
+ "frame": {
+ "description": "Reference frame of the positions.",
+ "type": "string"
+ },
+ "input_sha256": {
+ "description": "SHA-256 of the canonical input.",
+ "type": "string"
+ },
+ "llm_used": {
+ "description": "Always false: no language model is involved.",
+ "type": "boolean"
+ },
+ "payment": {
+ "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+ "type": "object"
+ },
+ "reproducibility": {
+ "description": "How to reproduce and check this result.",
+ "type": "string"
+ },
+ "result_sha256": {
+ "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "deterministic",
+ "llm_used",
+ "input_sha256",
+ "result_sha256"
+ ],
+ "type": "object"
+ },
+ "result": {
+ "description": "The calculation result.",
+ "properties": {
+ "dasha": {
+ "description": "Vimshottari dasha: system, year length, depth, balance at birth, the mahadashas with their antar and pratyantar periods and exact dates, and the periods running now ('current').",
+ "type": "object"
+ },
+ "moon": {
+ "description": "The natal Moon the dashas start from: sidereal longitude, rashi, nakshatra, pada and fraction elapsed.",
+ "type": "object"
+ },
+ "settings": {
+ "description": "Settings applied: sidereal zodiac, ayanamsa (name and value in degrees), lunar node type, house system and divisional-chart rules.",
+ "type": "object"
+ },
+ "subject": {
+ "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
+ "type": "object"
+ },
+ "warnings": {
+ "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+ "type": "array"
+ }
+ },
+ "required": [
+ "subject",
+ "settings",
+ "moon",
+ "dasha"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "endpoint",
+ "result",
+ "meta"
+ ],
+ "type": "object"
+}aspects4 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Western convention."Input schema / properties / options / properties / house_system / descriptionAdded value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."Input schema / properties / options / properties / luminary_orb_bonus / descriptionAdded value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."Input schema / properties / options / properties / zodiac / descriptionAdded value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."doshas3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."gun_milan3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."kundli3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."kundli_full3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."nakshatras3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."natal_chart4 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Western convention."Input schema / properties / options / properties / house_system / descriptionAdded value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."Input schema / properties / options / properties / luminary_orb_bonus / descriptionAdded value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."Input schema / properties / options / properties / zodiac / descriptionAdded value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."panchang3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."planet_positions4 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Western convention."Input schema / properties / options / properties / house_system / descriptionAdded value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."Input schema / properties / options / properties / luminary_orb_bonus / descriptionAdded value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."Input schema / properties / options / properties / zodiac / descriptionAdded value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."synastry6 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Western convention."Input schema / properties / options / properties / house_system / descriptionAdded value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."Input schema / properties / options / properties / luminary_orb_bonus / descriptionAdded value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."Input schema / properties / options / properties / zodiac / descriptionAdded value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."Input schema / properties / person_a / descriptionAdded value: +"First person's birth data."Input schema / properties / person_b / descriptionAdded value: +"Second person's birth data."transits7 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Western convention."Input schema / properties / options / properties / house_system / descriptionAdded value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."Input schema / properties / options / properties / luminary_orb_bonus / descriptionAdded value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."Input schema / properties / options / properties / zodiac / descriptionAdded value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."Input schema / properties / window / properties / end / descriptionAdded value: +"Last UTC date, YYYY-MM-DD, at most 366 days after start."Input schema / properties / window / properties / include_moon / descriptionAdded value: +"Also time the fast Moon transits; the window is then limited to 62 days."Input schema / properties / window / properties / start / descriptionAdded value: +"First UTC date, YYYY-MM-DD. Example: '2026-10-01'."vedic_report3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."verify_result_hash2 fields changedInput schema / properties / result / descriptionAdded value: +"The 'result' object exactly as a tool returned it."Input schema / properties / result_sha256 / descriptionAdded value: +"The meta.result_sha256 returned with it (64 hex characters). Omit to only recompute the hash."vimshottari_dasha3 fields changedInput schema / properties / options / descriptionAdded value: +"Optional calculation settings; every default is the common Parashari convention."Input schema / properties / options / properties / ayanamsa / descriptionAdded value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."Input schema / properties / options / properties / include_outer_planets / descriptionAdded value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."aspectsastro_catalogdoshasgun_milankundlikundli_fullnakshatrasnatal_chartpanchangplanet_positionsresolve_birth_timesynastrytransitsvedic_reportverify_result_hashvimshottari_dashaVedic astrology (Jyotish): birth charts, divisional charts, dashas, yogas, transits, panchang
Sub-arcsecond astrology on NASA JPL DE440: natal, transits, Human Design, Vedic, BaZi.
Ephemeris natal & mundane charts, Vimshottari Dasha, transit horoscopes, Horas, and Vedic yogas.
Vedic astrology from a real ephemeris: birth chart, life-event timing and Kundli matching.
Add one secure layer between your agents and this server.
