Vedic astrology for AI agents: kundli, daśā, guna milan, life, venture and gem readings, ephemeris.
Scored across 21 tools
Most tools target clearly distinct deliverables, and the descriptions go out of their way to cross-reference near-neighbours (get_guna_milan vs get_compatibility, interpret_domain vs get_forecast, get_domain_timeline as a slice of get_life_reading). The remaining soft spots are real: get_forecast and resolve_timing both take a domain plus question and are both LLM-voiced, and daśā output appears in get_chart, get_dasha and get_techniques, so an agent must read carefully to pick.
Every tool is snake_case verb_noun (get_chart, find_muhurta, assess_gemstone, interpret_domain), with a clean get_ephemeris_* prefix grouping the five ephemeris primitives. No mixed casing or idiosyncratic verbs anywhere.
At 21 tools this sits above the comfortable band, but the surface is broad (natal reading, compatibility, muhurta, horary, gemstones, five atomic ephemeris computations) and each tool maps to a distinct deliverable rather than a variant of another. The count is defensible, though a few reading tools could collapse into parameterised options.
Coverage is strong across the lifecycle: chart casting, divisional charts, daśās, interpretation, timing, muhurta, praśna, compatibility, relationship, career and ephemeris primitives, with clear cost/latency trade-offs offered at two granularities. Gaps are minor: no dedicated gochara/transit-to-natal overlay (only raw ephemeris series), no birth-time rectification, and remedies are limited to gemstones.
Use this when the user asks whether they should wear a particular gemstone (blue sapphire, emerald, pukhraj, a crystal), or whether a stone they wear suits their chart.
Answers the prescription, not the future: which planet the stone strengthens, what that planet owns from this ascendant, whether a classical rule (a dusthāna or kendrādhipati lordship, a māraka) argues against strengthening it, and whether the reason is permanent or lasts only as long as the running period. Returns a verdict — well_founded, period_bound, no_ground, contraindicated or unrecognised — with every ground for and against, the planet's capacity at its degree, when the chart puts the planet in scope, the stones the sources hold apart from it (checked against alsoWearing), and wearing detail (finger, metal, day, weight, with the book it comes from) only when the chart gives a reason to wear it. When the source states a caution about the stone, the response says so and names the book. A word that covers several stones ("sapphire") is answered with the candidates. Nothing here predicts what a stone does. Deterministic: no language model is called. The birth time is required.
Cost: 5 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"gem":"blue sapphire","alsoWearing":["ruby"]}
| Name | Required | Description | Default |
|---|---|---|---|
| gem | Yes | One stone, in English or by its Indian name: "yellow sapphire", "pukhraj", "emerald", "moonstone". | |
| birthData | Yes | The person's birth data. The time is required: every period depends on the rising sign. | |
| alsoWearing | No | Optional: stones already worn. When the chart puts the planet in scope, a pairing the sources hold apart is reported as a conflict. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 beyond them: 5 credits per call charged only on success, a free sandbox key, full determinism with no model called, the enumerated verdict vocabulary, that cautions are surfaced with the source book named, and that ambiguous stone names return candidate lists. This is exactly the extra disclosure the dimension rewards.
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?
Well front-loaded: trigger, then semantics of the answer, then returns, then cost. It loses a point for internal repetition — determinism is asserted twice ('Deterministic: no language model is called' and 'Deterministic: the same input always gives the same answer') and the prescription/not-future point is restated as 'Nothing here predicts what a stone does'.
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 nested, multi-parameter tool with an output schema, the description covers everything an agent needs: the trigger, the resolution of ambiguous inputs, the conflicting-stone check, the charged/un-charged cost model, and the determinism guarantee. Return-value detail is supplemented rather than duplicated, which is appropriate given the 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 coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining how the `gem` value is resolved (English or Indian name, multi-stone words answered with candidates) and that `alsoWearing` is checked against the source-listed incompatible pairings when the planet is in scope. It also reinforces that birth time is required rather than optional.
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 opening sentence states a specific trigger verb and resource — deciding whether a gemstone should be worn, or whether a worn stone suits the chart — and explicitly bounds the scope as 'the prescription, not the future'. No sibling tool (get_chart, get_forecast, get_guidance) does gemstone prescription, so the agent can route here without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use conditions (user asks about wearing a stone, or whether a worn stone suits the chart) plus a scoping exclusion ('Nothing here predicts what a stone does'). It stops short of naming the alternative sibling an agent should use for predictive questions, so the exclusion is left implicit rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for an auspicious date or time (muhūrta) to do something, such as a wedding, launch, move or purchase, within a date range at a given place.
Scans each day in the range and ranks windows for the subject. The pañcāṅga is computed for eventPlace, never defaulted to the birthplace.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"subject":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"eventPlace":{"latitude":19.076,"longitude":72.8777,"timezone":"Asia/Kolkata","label":"Mumbai"},"freeText":"signing a lease","rangeStart":"2026-11-01","rangeEnd":"2026-11-15"}
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No | How many ranked windows to return. Default 5. | |
| eventId | No | Event type identifier, if known. | |
| subject | Yes | Birth data of the person the event is for; windows are ranked against their chart. | |
| freeText | No | The event described in words, when there is no eventId. | |
| rangeEnd | Yes | Last date to search, YYYY-MM-DD. | |
| timeOfDay | No | Local time (HH:MM) at which each day is evaluated. Default: local sunrise. | |
| eventPlace | Yes | Where the event will happen: latitude, longitude and IANA timezone. The pañcāṅga is computed here, never at the birthplace. | |
| rangeStart | Yes | First date to search, YYYY-MM-DD. | |
| subjectName | No | Optional name of the subject, used only in the response text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only annotations by disclosing cost (10 credits, only successful calls charged, sandbox free), determinism, and the critical rule that the pañcāṅga is computed at eventPlace and never the birthplace. It doesn't state output shape or ranking criteria, but the output schema exists to cover returns.
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?
Five focused lines with the trigger front-loaded, then mechanism, cost, determinism, and an example. The example arguments line is long but valuable for a 9-parameter nested-object tool; nothing is truly 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?
The tool has a rich nested schema and an output schema, so the description needn't explain returns. It covers the trigger, mechanism, cost, and the eventPlace-vs-birthplace distinction, which are the highest-risk ambiguities. Slightly more on ranking/selection versus siblings would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds the non-obvious semantic rule that eventPlace drives pañcāṅga computation rather than birthplace, but otherwise does not add format or constraint detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (scans/ranks) and resource (auspicious windows/muhūrta) with concrete trigger scenarios (wedding, launch, move, purchase). It clearly distinguishes itself from generic timing siblings like resolve_timing or get_venture_timing by naming the muhūrta concept and pañcāṅga basis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the trigger: when the user asks for an auspicious date/time for an event within a date range at a place. It doesn't name an alternative or exclusion (e.g. versus resolve_timing), so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants their birth chart (kundli): ascendant, planets in signs and houses, yogas, the current planetary periods, or a divisional chart such as the navāṁśa (D9).
Sidereal (Lahiri) chart: ascendant, the nine grahas, twelve houses, yogas and the Vimśottarī daśā. A modern Western block is added unless western is false. With location, also astrocartography lines at that place and the chart's own frame relocated there. Includes the D9 and D10 divisional charts by default; ask for any of the sixteen ṣoḍaśavarga with divisionals.
Cost: 1 credit per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}
| Name | Required | Description | Default |
|---|---|---|---|
| western | No | Set false to omit the modern Western block. | |
| location | No | Both coordinates or neither: a half-filled location is refused, never defaulted. | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| divisionals | No | Divisional charts (vargas) to include: any of the sixteen ṣoḍaśavarga. Default d9 (navāṁśa) and d10 (daśāṁśa); send [] for none. Each returns its ascendant and every graha's sign, degree and house within the varga, by the Parāśari formulas. | |
| includeDasha | No | Include the Vimśottarī daśā periods in the chart response. Default true. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, it discloses cost (1 credit per successful call), sandbox behavior, determinism, default inclusion of D9/D10, and the effect of passing `location` or omitting birth time. These are meaningful behavioral traits that help an agent predict billing and output shape.
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 definition is front-loaded with the usage trigger and is dense with useful details, but the first two sentences partially repeat the same chart components. It remains efficient overall because cost, determinism, defaults, and the example each add value.
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 nested, multi-parameter chart tool with an output schema, the description covers the essential context: what is returned, defaults, location behavior, unknown-time behavior, billing, determinism, and an example. Nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents most parameters, but the description adds practical meaning: `western: false` omits the modern block, `location` triggers astrocartography and relocation, and `divisionals` controls which vargas are returned. It also supplies a complete example argument for `birthData`.
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 usage trigger and resource: the user's birth chart (kundli), then enumerates exactly what is returned, including ascendant, grahas, houses, yogas, periods, and divisional charts. It distinguishes the tool from sibling ephemeris and compatibility tools by anchoring it to the natal-chart use case.
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 the tool: when the user wants their birth chart or specific natal components such as yogas or D9. It also explains conditional behavior for `location`, `western`, and `divisionals`, though it does not explicitly say when to prefer sibling tools like `get_dasha` for standalone period queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether two people are a good match for marriage and wants the full reading, not only a score. For the fast 36-point score with Manglik alone, use get_guna_milan.
Both charts read together for marriage. The 36-point Aṣṭakūṭa (guna milan) is one input: the verdict names the governing factor and says when it outweighs the score. Also returned: each chart's marital promise, sustainability and happiness, progeny, Manglik reckoned from the lagna, the Moon and Venus with mutual cancellation, a joint marriage-timing window, synastry, and caveats where an uncertain birth time would change the reading. Deterministic: no language model is called. Each partner is a BirthData object plus optional name and gender.
Cost: 12 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First partner: birth data plus optional name and gender. | |
| b | Yes | Second partner: birth data plus optional name and gender. | |
| referenceDateIso | No | ISO date the reading is anchored to. Defaults to now. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations (which only cover readOnly/idempotent/no-destruction) by disclosing determinism with no LLM call, cost of 12 credits with charging rules, a free sandbox key, and the caveat that uncertain birth times change the reading. It also enumerates the substantive outputs (verdict, marital promise, Manglik reckoning, timing window, synastry), which is the behavioral context an agent needs to set expectations.
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 when-to-use and the sibling routing, then layers detail efficiently. It loses a point for redundancy: determinism is asserted twice ('no language model is called' / 'the same input always gives the same answer'), which could be a single clause.
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 nested-input, paid, deterministic tool with an output schema, the description covers trigger, alternative, inputs shape, cost, determinism, and the limits of accuracy under unknown birth time. Nothing needed to invoke 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 already 100%, so the baseline would be 3, but the description adds the structural note that each partner is a BirthData object plus optional name/gender and supplies a complete worked example argument object. The referenceDateIso anchoring is left to the schema, which is a minor omission given the otherwise strong supplementation.
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 ('reads both charts together for marriage') and pins the scope as the full reading rather than a bare score. It explicitly distinguishes itself from the sibling get_guna_milan, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with the trigger condition ('when the user asks whether two people are a good match for marriage and wants the full reading') and names the alternative plus the condition that selects it ('fast 36-point score with Manglik alone, use get_guna_milan'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which planetary period (daśā) they are in, when it ends, or which periods are coming. The current periods include the running pratyantardaśā; send depth 'pratyantardasha' for the full timeline at that level. Cost: 1 credit per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Timeline depth. 'pratyantardasha' nests the pratyantardaśās under each antardaśā (about ten times larger). The current periods always include the running pratyantardaśā. | antardasha |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds genuinely new operational facts: 1 credit per call, only successful calls charged, sandbox key free with fixed sample, and deterministic results. That is meaningful context beyond the structured fields, though it says nothing about auth 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?
Four short sentences, front-loaded with the trigger condition, followed by depth guidance, cost, determinism, and an example. Every line carries information, though the example-arguments block partially duplicates what the schema already specifies.
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 and rich annotations, the description only needs to cover selection, cost, and determinism — all of which it does. Nested birthData structures are documented in the schema, so nothing an agent needs to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds a subtlety the schema does not state as directly: current periods always include the running pratyantardaśā, and requesting depth 'pratyantardasha' expands the timeline roughly tenfold. This helps an agent pick a depth value correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: retrieving the Vimśottarī daśā timeline of planetary periods, with scope framed by the user's question ('which planetary period they are in, when it ends, or which are coming'). It is clear without opening the schema, though it does not explicitly distinguish itself from potentially overlapping siblings like get_domain_timeline or resolve_timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger conditions tied to user intent ('when the user asks which planetary period...'), plus a decision rule for the depth parameter. No explicit when-not or alternative-tool guidance, which keeps it out of 5 territory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about one area of life — when marriage, children, career, money, property or another area is in focus, or what a given stretch of years holds for it.
One life area across the whole life: the planets that govern it on this chart, every period that bears on it (past and future, with dates, ages and why that planet governs it), each marked primary when the area is in focus or also when the period only touches it, and what is in focus now and next, in plain words. Pass window to get only the periods that overlap a date range. It is the same reading as the whole-life reading, cut to one area, so the two never disagree. Health is read only as periods to give extra care, never as illness or lifespan. Deterministic: no language model is called. The birth time is required.
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"area":"relationship","window":{"from":"2026-01-01","to":"2031-12-31"}}
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | The life area. | |
| window | No | Optional: only periods overlapping this date range (YYYY-MM-DD). Default: the whole life. | |
| birthData | Yes | The person's birth data. The time is required: every period depends on the rising sign. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/deterministic safety, and the description adds genuinely new behavioral facts: cost of 3 credits per call, charging only on success, a free sandbox key returning a fixed sample, that no language model is invoked, and the health-read boundary (periods for extra care, never illness or lifespan). No contradiction with annotations; the cost and health caveats go well beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the triggering scenario, then output shape, then parameters, cost and example — a sensible ordering with little waste. Slightly padded by stating determinism twice ('no language model is called' and 'the same input always gives the same answer'), which is also partly redundant with idempotentHint.
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 need not detail return values, and it still summarizes them; annotations cover the safety profile; and all three parameters are documented in the schema plus reinforced in prose. Determinism, cost, health caveat and an example call close the remaining gaps for a callable tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaning: `window` is framed as 'only the periods that overlap a date range,' the birth time requirement is emphasized ('The birth time is required'), and a full example argument object shows correct nesting of birthData/area/window. That said, it does not explain the distinguishing semantics of the 11 enum areas.
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 (a timeline for one life area) and scopes it precisely: 'one life area across the whole life.' It explicitly differentiates from the whole-life sibling by saying it is 'the same reading as the whole-life reading, cut to one area, so the two never disagree.' An agent can route between get_domain_timeline and get_life_reading without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('when the user asks about one area of life — marriage, children, career, money, property') and contrasts the whole-life reading as the alternative, plus notes `window` for narrowing to a range. It stops short of naming sibling tools explicitly (e.g. get_life_reading, interpret_domain), leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need the ascendant, midheaven or house cusps for a moment and place. Ascendant, midheaven and twelve cusps for a moment and place. Placidus is undefined beyond the polar circles at some moments; the call then returns 422 houses_undefined_at_latitude. Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"datetime":"1990-05-12T14:35:00+05:30","latitude":28.6139,"longitude":77.209,"houseSystem":"placidus"}
| Name | Required | Description | Default |
|---|---|---|---|
| zodiac | No | sidereal (default) or tropical. | sidereal |
| ayanamsa | No | Sidereal only. | lahiri |
| datetime | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| latitude | Yes | Geographic latitude in decimal degrees, north positive. | |
| longitude | Yes | East positive. | |
| houseSystem | No | House system for the cusps: whole_sign (default), equal or placidus. | whole_sign |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the cost model (0.1 credit per call, billed per started block of 10, only successful calls charged, free sandbox key), determinism, and an error behavior (422 houses_undefined_at_latitude for Placidus beyond the polar circles). This is exactly the operational context annotations cannot 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-loaded with the purpose and tight overall, but the first sentence ("Use this when you need the ascendant, midheaven or house cusps...") and the second ("Ascendant, midheaven and twelve cusps...") restate the same fact, so one sentence is partly redundant.
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 no explanation, and the description covers the remaining agent-relevant facts: cost, determinism, the Placidus failure mode, and a worked example. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: the Placidus polar-circle limitation constrains how houseSystem can be used, and the example arguments object demonstrates a valid datetime-with-offset combination. That goes 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?
The description names a specific output set (ascendant, midheaven, twelve house cusps) for a given moment and place, which cleanly separates it from sibling ephemeris tools that return positions, ayanamsa or sunrise. It does not explicitly name a sibling to contrast with, but the resource is unambiguous.
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?
"Use this when you need the ascendant, midheaven or house cusps for a moment and place" is an explicit trigger condition, so the agent knows when this applies. There is no when-not guidance and no named alternative among the ephemeris siblings, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need an ayanamsa value (Lahiri, Raman, Krishnamurti, Fagan–Bradley) at a moment. Lahiri, Raman, Krishnamurti and Fagan–Bradley (mean, without nutation) at a moment. Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"datetime":"2026-10-06T00:00:00Z"}
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, destructive=false, so safety is covered. The description adds genuinely useful non-annotation context: the credit cost model, the free sandbox key, and the determinism guarantee. It stops short of describing the Fagan–Bradley mean-without-nutation caveat framing returned fields, but the added billing and determinism notes are valuable.
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 use-case, then system list, cost, determinism, and an example—each sentence earns its place. Slightly redundant phrasing between the first two lines ('at a moment' repeated), but overall tight and well-ordered.
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 single-parameter, read-only tool with a fully documented schema, output schema present, and annotations covering the safety profile, the description covers use-case, supported systems, pricing, and determinism. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the datetime parameter's format, range, and refusal behavior are already fully documented in the schema. The description's example argument adds a small amount of convenience but no meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieve an ayanamsa value at a moment, naming the four supported systems (Lahiri, Raman, Krishnamurti, Fagan–Bradley). This distinguishes it clearly from siblings like get_ephemeris_positions, get_ephemeris_angles, and get_ephemeris_series, which return different quantities.
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 opening 'Use this when you need an ayanamsa value ... at a moment' gives a clear triggering condition and names the acceptable systems. It does not, however, explicitly distinguish itself from the other get_ephemeris_* siblings or state when a different ephemeris tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need where the Sun, Moon and planets are at a moment (sidereal or tropical), not a reading.
Sun, Moon, planets and lunar nodes at one moment: longitude, latitude, distance, speed and retrograde flag, with sign, and nakṣatra and pada when sidereal. equatorial: true adds apparent right ascension and declination.
Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"datetime":"2026-10-06T06:00:00Z","bodies":["Sun","Moon","Mars","Jupiter","Saturn","TrueNode"],"zodiac":"sidereal","ayanamsa":"lahiri"}
| Name | Required | Description | Default |
|---|---|---|---|
| bodies | No | Default: all twelve. | |
| zodiac | No | sidereal (default) or tropical. | sidereal |
| ayanamsa | No | Sidereal only. | lahiri |
| datetime | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| equatorial | No | Also return apparent right ascension and declination. Default false. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: a concrete cost model (0.1 credit/call, billed per started block of 10, only successful calls charged, sandbox key free with fixed sample), an explicit determinism guarantee, and the sidereal/tropical output-shape difference. The read-only, idempotent and non-destructive profile is already carried by annotations, so this is genuinely additive rather than restated.
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 decision-relevant sentence, then payoff fields, cost, determinism and an example — each block is distinct and earns its place. The example arguments are mildly redundant given the 100%-covered schema, keeping it just short of ideal.
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 no explanation, yet the description still summarizes the payload shape. With 5 parameters, enums, billing and precision caveats all covered, an agent has everything needed to call this correctly on the first attempt.
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 already 100% and includes defaults and enum caveats (MeanNode/TrueNode = Rāhu, Ketu = node+180), so the baseline is 3. The description still adds value by pairing the sidereal mode with the nakṣatra/pada output and by supplying a complete, valid example argument set that shows how datetime, bodies, zodiac and ayanamsa combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('where the Sun, Moon and planets are at a moment') and enumerates exactly what is returned (longitude, latitude, distance, speed, retrograde flag, sign, nakṣatra/pada when sidereal). It explicitly distinguishes itself from the reading-oriented siblings with 'not a reading', which is the key ambiguity in this tool set.
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?
'Use this when you need ... at a moment ... not a reading' gives a clear positive trigger and a negative boundary against the many reading/interpretation siblings. It does not, however, route among the close ephemeris siblings (get_ephemeris_series for time ranges, get_ephemeris_angles, get_ephemeris_ayanamsa, get_ephemeris_sunrise), so an agent must infer that this is the single-moment variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need planetary positions across a range of dates, for a transit table or to find when a planet changes sign or stations. Positions from start to end (inclusive) every stepMinutes, for transit tables and station finding. At most 1,000 points (too_many_points beyond). A 365-point daily table costs 4 credits. Cost: 1 credit per started 100 points (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"start":"2026-10-01T00:00:00Z","end":"2026-10-10T00:00:00Z","stepMinutes":1440,"bodies":["Mercury","Venus"]}
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| start | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| bodies | No | Default: all twelve. | |
| zodiac | No | sidereal (default) or tropical. | sidereal |
| ayanamsa | No | Sidereal only. | lahiri |
| stepMinutes | Yes | Minutes between points (1 to 525,600). At most 1,000 points per call. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations: discloses the 1,000-point hard cap and the too_many_points failure, the credit pricing model per started 100 points, that only successful calls are charged, that sandbox keys return fixed samples, and that results are deterministic. These are exactly the operational facts an agent needs before spending credits.
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 trigger condition in the first clause, then layers scope, limits, cost, and an example in descending order of importance. The minor restatement of 'transit table/station finding' is tolerable and every other sentence carries new 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 available, the description doesn't need to explain return values, and it closes the remaining gaps an agent would hit: rate/point ceiling, error name, credit cost, and determinism. Zodiac and ayanamsa defaults are fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description earns an extra point by tying stepMinutes to output density ('every stepMinutes', '365-point daily table') and by supplying a worked example with real body names and stepMinutes=1440, which anchors the units and array format.
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 (planetary positions) with an explicit scope qualifier ('across a range of dates') and concrete ends (transit table, sign changes, stations). This implicitly separates it from get_ephemeris_positions, though it never names that sibling outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete situations that should trigger the tool — building a transit table, finding when a planet changes sign or stations. It stops short of explicit exclusions such as 'for a single moment use get_ephemeris_positions instead', so the agent must infer the boundary from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need sunrise and sunset for a date and place, or where the Vedic day begins. Sunrise, sunset and the next sunrise for a local date and place: upper limb at the sea-level horizon with 36.6′ refraction. The Vedic day runs from sunrise to the next sunrise. Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"date":"2026-10-06","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Local calendar date, YYYY-MM-DD. | |
| latitude | Yes | Geographic latitude in decimal degrees, north positive. | |
| timezone | Yes | IANA name, e.g. Asia/Kolkata. Defines the local day. | |
| longitude | Yes | East positive. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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), yet the description adds material context the annotations cannot: cost model (0.1 credit/call, billed per 10-call block, only successful calls charged, free sandbox key with fixed sample) and determinism. That is exactly the kind of operational disclosure an agent needs before spending credits.
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 when-to-use clause, then the precise geometric definition, cost, determinism, and an example. Well ordered and mostly tight; the billing sentence is the longest but earns its place for a paid tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be re-described, and the description covers everything else an agent needs: when to call it, the exact astronomical convention, cost, determinism, and a sample invocation. Complete for a 4-param read-only computation.
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 all four parameters carry their own descriptions (date format, IANA timezone, lat/long sign conventions), so the schema does the heavy lifting. The description's example arguments add a concrete usage pattern but no new constraint or syntax beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific computation (sunrise, sunset, and next sunrise) for a given date and place, and precisely defines what 'sunrise' means here (upper limb at sea-level horizon with 36.6′ refraction). This distinguishes it from generic ephemeris siblings like get_ephemeris_positions or get_ephemeris_angles.
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?
'Use this when you need sunrise and sunset for a date and place, or where the Vedic day begins' gives clear triggering context, including the Vedic-day use case that motivates the tool. It stops short of naming which sibling to use instead when the agent wants angles or planetary positions, so no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks an open question about what lies ahead in one area of life and wants a written answer. It takes tens of seconds; for a fast, structured verdict use interpret_domain.
The interpret verdict for domain, voiced as a narrative answer to question by a language model grounded in the classical statements for the domain. Expect tens of seconds; set a client timeout of at least 90 s.
Cost: 8 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Voiced by a language model: allow up to 90 seconds.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"How will the next year unfold for my work?"}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Life area the question is about, e.g. career, marriage, finance or health. | |
| question | Yes | The question in plain language, e.g. "What does the next year hold for my career?" | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotency profile; the description adds the costly operational facts an agent needs: tens-of-seconds latency with a >=90 s client timeout, 8 credits per call charged only on success, and a free sandbox key that returns a fixed sample. These are exactly the traits annotations cannot express.
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 routing rule and then the cost/latency facts, and the example earns its space. However, latency is stated three separate times ('takes tens of seconds', 'set a client timeout of at least 90 s', 'allow up to 90 seconds'), which is redundant padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not required, and cost/latency/routing are covered. The description is nearly complete, but the triple restatement of timing leaves it slightly less tight than it could be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description goes beyond that with a complete example argument object showing the birthData shape, a concrete domain value and question phrasing. It adds a worked invocation rather than restating field docs.
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 and resource ('written answer about what lies ahead in one area of life') and explicitly contrasts with the sibling interpret_domain ('for a fast, structured verdict use interpret_domain'). An agent can tell it apart from the structured-verdict tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit triggering condition ('when the user asks an open question about what lies ahead') plus the alternative route ('for a fast, structured verdict use interpret_domain'). Routing is fully determined by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how to conduct themselves in the period they are in: what to do and what to take care with, each with its classical reason. Guidance, not prediction.
Plain-language guidance cards for each running daśā level (mahādaśā, antardaśā, …) at referenceDate (default: now).
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}
| Name | Required | Description | Default |
|---|---|---|---|
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| referenceDate | No | ISO date or datetime. Defaults to now. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive, closed-world), so the description wisely spends its budget on behavior the annotations cannot convey: credit cost per call (3, charged only on success), a free sandbox key returning a sample, and deterministic output. These are exactly the operational traits an agent needs before committing to a 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?
Front-loaded with the usage trigger before mechanics, and the cost/determinism lines are short and earn their place. The inline example-arguments JSON is slightly heavy but directly aids invocation, so the cost is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and it fills the remaining gaps: trigger condition, billing model, determinism guarantee, and a worked argument example. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents birthData, its nested fields, timezone format and referenceDate defaults. The description only restates the referenceDate default (already in the schema) and adds an example argument set, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Plain-language guidance cards for each running daśā level') and draws a useful contrast ('Guidance, not prediction'). This conceptually separates it from raw-data tools like get_dasha, but it never names or explicitly distinguishes itself from its actual siblings, so the differentiation is implied rather than stated.
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 opening sentence gives clear usage context: use it when the user asks how to conduct themselves in their current period, with the reason that distinguishes it from pure prediction. It provides no explicit exclusions or named alternatives, so an agent must infer when to pick get_dasha or get_forecast instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for the guna milan / kundli matching score (out of 36), or whether either person is Manglik. The classical Aṣṭakūṭa match for a pair (all eight kūṭas, with the Bhakoot and Nāḍī doṣas) and Manglik for both charts reckoned from the lagna, the Moon and Venus, with mutual cancellation. The same engine as /v1/compatibility, without the full reading: the score is one input, and /v1/compatibility reads each chart's marital promise, timing and doṣas on top of it. Deterministic, no language model. Cost: 2 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First partner: birth data plus optional name and gender. | |
| b | Yes | Second partner: birth data plus optional name and gender. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds context beyond them: cost of 2 credits per call with only successful calls charged, a free sandbox key returning a fixed sample, and deterministic output. Billing and determinism are operationally important and are not derivable from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the usage trigger, then purpose, then differentiator, then cost/determinism facts; every sentence carries distinct information. The astrological vocabulary (Bhakoot, Nāḍī, lagna) makes it dense, but nothing is redundant.
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; the description still covers trigger, scope, the sibling alternative, cost, and determinism. For a two-parameter, closed-world read tool this is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by supplying a full worked example with both a and b birth-data objects, which clarifies the two-partner shape and required fields in practice. It does not elaborate on optional fields (name, gender) or the omitted-time behavior, which the schema already covers.
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: the Aṣṭakūṭa (guna milan) matching score out of 36 plus Manglik status for both charts. It also explicitly distinguishes itself from the closest sibling by noting it is 'the same engine as /v1/compatibility, without the full reading', so an agent can separate the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger ('Use this when the user asks for the guna milan / kundli matching score ... or whether either person is Manglik') and names the alternative (get_compatibility / /v1/compatibility) with the condition that selects it ('reads each chart's marital promise, timing and doṣas on top of it'). When-to-use and alternative routing are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants their life as a whole: which life areas (marriage, children, career, business, money, property, family, travel, education, spirituality, health) are in focus when, across past and future, and where life stands now.
The life's chapters (each mahādaśā in plain words, with dates and ages) and eleven life areas, each with the planets that govern it on this chart, every governing period past and future with why that planet governs it — each marked primary (the area is in focus) or also (the period only touches it) — and what is in focus now and next. Past periods are included, so the reading can be tested against a life already lived; send recorded events to place them on the timeline. Health is read only as periods to give extra care, never as illness or lifespan. Deterministic: no language model is called. The birth time is required. The full reading is large; pass areas to return only the life areas you need.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"areas":["career","relationship"],"recorded":[{"type":"job_start","date":"2012-07-01","certainty":"exact"},{"type":"marriage","date":"2018-11-25","certainty":"exact"}]}
| Name | Required | Description | Default |
|---|---|---|---|
| areas | No | Optional: only these life areas (default all eleven). The full reading is large, so an AI agent answering about one area should pass it here. | |
| recorded | No | Optional dated life events to place on the timeline. | |
| birthData | Yes | The person's birth data. The time is required: every period depends on the rising sign. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: cost (10 credits, charged only on success), free sandbox key with fixed sample, full determinism with no LLM, large response size, birth time required, past periods included and testable against recorded events, and the ethical caveat that health is read only as periods for extra care. This is unusually rich behavioral context for a read-only tool.
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 when-to-use condition and generally dense with useful content, but it is long and repeats itself — "Deterministic" appears in two separate sentences ("no language model is called" and "the same input always gives the same answer"). A small trim would tighten it without losing meaning.
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 documented, and the description still orients the agent on output shape (chapters, eleven areas, primary/also markers, now/next). Combined with annotations covering the safety profile and the cost/determinism notes, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics: why to pass `areas` (the full reading is large), what `recorded` is for (placing lived events on the timeline), and which field is strictly required. It enriches the schema rather than restating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (a whole-life reading) and enumerates the exact scope it covers — life's chapters (mahādaśās) and eleven named life areas with dates, ages, and governing planets. It is clearly distinguishable from siblings like get_relationship_reading, get_domain_timeline, or interpret_domain, which cover narrower slices.
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?
"Use this when the user wants their life as a whole" gives an explicit trigger, and it even hints at the narrower path ("pass `areas` to return only the life areas you need"). It does not name the specific sibling tools to use instead for a single domain, so routing to alternatives is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks a specific question and wants it answered from the moment of asking rather than from a birth chart — "will this deal close?", "will I recover?", "will I find what I lost?" — or when a KP astrologer gives a horary number 1–249. Send where the user is as place; it is never defaulted.
The chart of the moment and place a question is asked, read on the classical praśna rules, no model. Always: the praśna lagna and its lord, the Moon, the house of the matter asked about, the hand-encoded classical dicta that apply (recovery from illness for a health question; recovery of a lost article when the question names one), and the rules from the praśna books in the corpus that held on this chart, each with its book and the chart facts that made it hold. With deal: the deal praśna — significators (lagna lord = you, 7th = the other side, 10th = the undertaking, 11th = gain), their Tājika contacts, the grounds for and against, and an ordered verdict (perfects, perfects after obstacles, contested, delayed, delayed and contested, not perfected); add birthData for the natal commitment calendar beside it, never blended with it. With horaryNumber (1–249): the KP horary table — Placidus cusps in the Krishnamurti ayanāṁśa for the moment that sub rises, planets at the moment of judgment, sign/star/sub/sub-sub lords, and the ruling planets; no KP judgment is asserted. Rules about caste, prenatal sex or death timing are withheld and counted.
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"place":{"latitude":28.6139,"longitude":77.209,"timezone":"Asia/Kolkata","label":"New Delhi"},"askedAt":"2026-10-14T10:30:00+05:30","question":"Will the supply contract with Northwind be signed?","deal":{"label":"Northwind supply contract","kind":"contract","signingDate":"2026-11-02"},"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"horaryNumber":108}
| Name | Required | Description | Default |
|---|---|---|---|
| deal | No | Read the question as one deal (the deal praśna). | |
| place | Yes | Where the question is asked. Required: a praśna cast at the wrong longitude is a different chart. | |
| domain | No | What the question is about: picks the house of the matter and scopes the book rules. With a deal and no domain, the deal's own. | |
| askedAt | No | The instant the question was asked, ISO 8601 with Z or an offset. Default: now. Send this or askedAtLocal, not both. | |
| question | No | The question in the user's words. Gates the lost-article dictum; it does not choose the domain. | |
| birthData | No | Only with `deal`, and with a birth time: the querent's natal commitment calendar is set beside the praśna for the signing date. | |
| askedAtLocal | No | The wall clock at the place when the question was asked, YYYY-MM-DDTHH:mm, read in place.timezone. | |
| horaryNumber | No | A KP horary number: adds the KP horary table. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds materially beyond them: credit cost and billing behavior (3 credits, only successful calls charged, free sandbox key), determinism ('same input always gives the same answer'), no-model epistemics, and, importantly, that caste/prenatal-sex/death-timing rules are withheld and counted, and that no KP judgment is asserted.
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 usage trigger, then organized into one block per mode, so it scans well. It is long, however, and spends considerable space narrating output contents (lagna lord, Moon, Tājika contacts, verdict vocabulary) that the existing output schema could carry, which dilutes conciseness somewhat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 8-parameter tool with nested objects, one required field, and an output schema, the description covers the remaining gaps an agent needs: the mode-selection logic, the credit/auth model, the withholding policy, the determinism guarantee, and a full worked example. Nothing material for correct invocation is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already carries most parameter meaning and the baseline is 3. The description still adds value by stressing that `place` is required and 'never defaulted' (a wrong longitude is a different chart), tying `birthData` to the deal mode rather than blending it, and explaining what `deal` and `horaryNumber` each cause the tool to compute.
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 (casting the praśna chart of the moment and place) and explicitly distinguishes itself from natal-chart siblings: 'answered from the moment of asking rather than from a birth chart'. It also enumerates the three distinct modes (plain question, deal praśna, KP horary number), so an agent can tell exactly what it returns versus get_chart or get_venture_timing.
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?
Opens with an explicit trigger condition ('when the user asks a specific question and wants it answered from the moment of asking') and gives the alternative it is not. It then states the selection conditions for each mode: use `deal` for a commercial question, `horaryNumber` 1–249 for a KP astrologer's number, and `birthData` only alongside `deal`. When/when-not/alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how two people get on in a bond other than marriage — business partners, siblings, a parent and child, or friends. Reads the bond the way the classical method reads it: the houses that govern this kind of bond and their lords in each chart, the natural significators, whose planets fall in whose governing houses, and whether that reach runs both ways, plus the running periods in each chart that engage the bond. A bond meter (strong tie, workable or strained) is computed by a stated convention and returned with every point it is built from; it is not a classical score, since the texts give no arithmetic for a business or sibling match. Deterministic: no language model is called. Both birth times are required. For marriage, use the compatibility tool. Cost: 8 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"type":"business","a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First person: birth data (time required) plus optional name. | |
| b | Yes | Second person: birth data (time required) plus optional name. | |
| type | Yes | The bond. For marriage, call /v1/compatibility. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety/idempotency but the description adds what they cannot: the classical method used, that the bond meter is a stated-convention composite rather than a classical score, that no language model is called, that both birth times are required, per-call cost with sandbox behavior, and determinism. This is exactly the extra context the annotations don't 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-loaded with the triggering condition, then method, caveats, cost, and determinism. Slightly long and 'Deterministic' is stated twice, but every section carries information. Deducted one for the 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?
An output schema exists, so return-value explanation isn't needed. For a two-person computation tool with cost, determinism, method, and required-input caveats all stated, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema, which sets the baseline at 3. The description adds only that both birth times are required — real but marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (reads) and resource (the bond between two people, non-marital) and enumerates the bond types it covers. It explicitly distinguishes itself from the marriage sibling tool twice, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the exact triggering condition ('when the user asks how two people get on in a bond other than marriage'), lists the covered relationship types, and names the alternative for marriage ('For marriage, use the compatibility tool'). When-to-use and when-not-to-use are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user or an astrologer asks for a specific classical computation — Ṣaḍbala, Aṣṭakavarga, Yoginī/Chara/Nārāyaṇa daśā, Varṣaphal, KP cusps, a named yoga, the birth pañcāṅga, Kuja doṣa, house lords and aspects — rather than for a reading. Pass sections to fetch only what is needed.
The computed classical working for a chart, no model: Ṣaḍbala and bhāva bala (BPHS 27), Aṣṭakavarga with trikoṇa/ekādhipatya reduction and piṇḍas, the Aṣṭottarī, Kālacakra, Nārāyaṇa, Yoginī and Chara daśās with the periods running at referenceDate, the full Vimśottarī ladder, the Varṣaphal (Tājika annual chart) for the year running at referenceDate, KP cusps with sub-lords and ruling planets (labelled KP only when the KP frame was computed), classical and Nābhasa yogas, kārakāṁśa, argala, special lagnas, bhāva chalit, the natal pañcāṅga, house lords with graha dṛṣṭi, Kuja doṣa with its exceptions, and what would change under the Raman or KP ayanāṁśa. Each section is {computed: true, data} or {computed: false, reason} — a technique that cannot be computed for this chart (for example without a birth time) says why and the rest still return. No verdicts, scores or lifespan figures.
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"sections":["shadbala","dashas","panchanga"],"referenceDate":"2026-10-14T00:00:00Z"}
| Name | Required | Description | Default |
|---|---|---|---|
| sections | No | Return only these sections. Default: all. | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| residence | No | Where the person lives; the Varṣaphal is cast for this place. Defaults to the birthplace. | |
| referenceDate | No | ISO date or datetime for the running periods and the Varṣaphal year. Defaults to now. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds substantial context beyond them: 3 credits per call, only successful calls charged, free sandbox key returning a fixed sample, determinism, the per-section {computed:true/false, reason} failure contract, and the explicit absence of verdicts/scores/lifespan figures.
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 when-to-use trigger and then the return contract, with cost/determinism grouped at the end. The second paragraph is a dense run-on catalogue of every section and the example-arguments block repeats schema content, adding length without much marginal routing value.
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 need not explain return shapes, yet it still documents the computed/computed-false envelope, credit cost, determinism, and degraded behavior without a birth time. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description rises above baseline by explaining what each section name actually computes (e.g. Aṣṭakavarga reductions and piṇḍas, daśās running at referenceDate, Varṣaphal cast for residence), which gives the enum values meaning the bare schema strings do not.
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 opening sentence names a specific verb+resource (classical computations for a chart) and enumerates the exact techniques returned. It explicitly distinguishes itself from reading-oriented siblings with 'rather than for a reading', so an agent can separate it from get_life_reading/get_relationship_reading/get_guidance without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States a clear trigger ('when the user or an astrologer asks for a specific classical computation') and an explicit exclusion (not for a reading). It does not, however, route the agent to overlapping siblings such as get_dasha or get_chart, which partially duplicate the daśā and chart sections here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks when to start, launch, sign, borrow or expand a business, or which line of business their chart supports.
A calendar of the coming months in four labels — commit (sign, open, launch), build (keep building; commit only what can be undone), guarded (low fixed cost; no lease, no borrowing) and hold (no new fixed commitments) — each window with the daśā period running and the slow transits of Saturn and Jupiter over it, and the reasons. Describe the businesses being weighed in ventures and each is ranked on how strongly the chart supports it and whether the coming periods carry it, with the grounds, its best coming period, and a caution when it needs premises during a hold; name none and the full catalogue of business types is ranked. A ranking of chart support, never a probability of success. Deterministic: no language model is called. The birth time is required.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"ventures":["software and data platform for businesses","a restaurant in a leased storefront","OneDot"],"months":36}
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | How far ahead the calendar runs, and the horizon each venture's period support is averaged over. | |
| ventures | No | Optional: the businesses being weighed, each described by what it does ("software for accountants", "a café with a leased storefront"). A brand name alone cannot be placed and is returned as unclassified. Omit to rank the whole catalogue. | |
| birthData | Yes | The person's birth data. The time is required: every period depends on the rising sign. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: pricing model (10 credits, only successful calls charged, free sandbox key), determinism and no LLM call, the birth time being mandatory, and the explicit meaning of each of the four calendar labels including constraints ('commit only what can be undone', 'no lease, no borrowing'). That is substantive behavioural disclosure an agent cannot get from readOnly/idempotent 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 use case and well organised, but it repeats determinism twice ('no language model is called' / 'the same input always gives the same answer'), which is one sentence of avoidable redundancy. Otherwise dense and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested-schema tool with four labelled windows and venture ranking, the description covers inputs, cost, determinism, required birth time, and venture-classification behaviour. An output schema exists, so return values need not be spelled out here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: ventures must be described by what they do, a brand name alone is returned unclassified, and omitting ventures ranks the whole catalogue. `months` semantics are already carried by 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+scope: a coming-months calendar labelled commit/build/guarded/hold, plus ranking of named business types. It is clearly distinguishable from siblings like get_domain_timeline, resolve_timing or find_muhurta. An agent can tell what it produces 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?
The opening 'Use this when the user asks when to start, launch, sign, borrow or expand a business, or which line of business their chart supports' gives clear triggering conditions. It does not explicitly name a sibling alternative or state when NOT to use it (e.g. vs resolve_timing for non-business timing), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what their chart says about one area of life (career, marriage, finance, health, property, children, education, travel, legal and others) and a reproducible verdict with its reasons and sources is wanted. Prefer it to get_forecast when no written narrative is needed. Deterministic reading of one life area: the verdict, the factors for and against it, timing windows, whether the engine's own methods agree, and the classical books the reading draws on. Every layer is declared as present, computed_empty, not_covered or failed, so nothing is silently missing. No language model is called: the same chart always gets the same reading. Cost: 5 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career"}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Life area to read, e.g. career, marriage, finance or health. | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing determinism, that no LLM is called, credit cost with a free sandbox key, and the layer-status model (present/computed_empty/not_covered/failed). This tells the agent exactly what behavior and safety profile to expect.
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 usage trigger, then behavior, cost, determinism (stated twice near-verbatim) and an example. The determinism restatement is redundant, but the structure is otherwise efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation; the description still covers cost, determinism, layer-status reporting, and the alternative tool. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already 100% and the enum documents all 15 domains, so baseline is 3. The description adds value with a concrete example-arguments payload showing the exact birthData/domain shape, though it doesn't add semantics the schema lacks.
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 (a deterministic reading of one life area) and enumerates the domains covered. It explicitly contrasts itself with the sibling get_forecast, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with a concrete trigger (user asks what their chart says about one life area and wants a reproducible verdict with reasons/sources) and names the alternative plus its selection condition: prefer this over get_forecast when no written narrative is needed. Explicit when and when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether now, or a particular date or range, is a good time for a decision such as changing jobs, marrying or investing. It takes tens of seconds.
The interpret verdict for domain, voiced by a language model as an answer to a decision question, read at targetDate (or the start of dateRange, or today when neither is sent): the verdict, the running daśā and eventTiming are taken at that day. A malformed or pre-birth date is refused with 400 (invalid_target_date, invalid_date_range). Expect tens of seconds; set a client timeout of at least 90 s.
Cost: 7 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Voiced by a language model: allow up to 90 seconds.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"Should I accept the offer?","targetDate":"2026-11-15"}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Life area the decision is about, e.g. career, marriage, finance or health. | |
| question | Yes | The decision question in plain language, e.g. "Is this a good time to change jobs?" | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| dateRange | No | Optional period the decision is about: start and end dates, YYYY-MM-DD. The verdict is read at `start`; `end` must not precede it. | |
| targetDate | No | Optional date the decision is about, YYYY-MM-DD. The verdict is read at this day. Takes precedence over `dateRange`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly annotations: credit cost (7 per call, sandbox free), latency and a 90 s client timeout, refusal behavior on malformed or pre-birth dates with specific 400 error codes, and what the verdict is read against. This is exactly the operational context annotations don't 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?
The latency warning is repeated three times ('takes tens of seconds', 'Expect tens of seconds', 'allow up to 90 seconds'), which is redundant. Front-loading is decent but the wall-clock caution should appear once to earn its 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?
For a nested-parameter, costly, slow tool with an output schema, the description covers the operational essentials: cost, timeout, error cases, and date precedence. Return-value detail is correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds real semantics: targetDate takes precedence over dateRange, the verdict is read at dateRange.start, and 'today' is used when neither is sent. That precedence rule is only in the description, not 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 trigger and resource: deciding whether a date/range is auspicious for a decision like jobs, marriage, or investing, and names the parameterized domain/question. It reads clearly but does not explicitly differentiate itself from close siblings like find_muhurta or get_venture_timing, which also concern timing.
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?
Opens with an explicit 'Use this when...' trigger scoped to a user asking about timing for a decision, which is strong context. However, it gives no when-not-to-use guidance or alternatives among the many timing-adjacent siblings, leaving the agent to infer the boundary.
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.
get_chart1 field changedInput schema / properties / location / properties / orbDegrees / descriptionAdded value: +"Orb as a ground distance in degrees of great-circle arc (1 degree = about 111 km at any latitude). Widened for an approximate birth time; no lines for an unknown one."get_ephemeris_positions2 fields changedInput schema / properties / bodies / items / descriptionPrevious value: -"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°."New value: +"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°. Every AstroNest chart, reading and timing endpoint uses the mean node."Output schema / $defs / EphemerisBody / descriptionPrevious value: -"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°."New value: +"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°. Every AstroNest chart, reading and timing endpoint uses the mean node."get_ephemeris_series2 fields changedInput schema / properties / bodies / items / descriptionPrevious value: -"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°."New value: +"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°. Every AstroNest chart, reading and timing endpoint uses the mean node."Output schema / $defs / EphemerisBody / descriptionPrevious value: -"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°."New value: +"MeanNode and TrueNode are Rāhu (mean or true); Ketu is the node + 180°. Every AstroNest chart, reading and timing endpoint uses the mean node."get_prashnaget_chart3 fields changedOutput schema / $defs / ChartResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "ascendant": {
- "properties": {
- "degree": {
- "type": "number"
- },
- "nakshatra": {
- "type": [
- "string",
- "null"
- ]
- },
- "sign": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "aspects": {
- "description": "The five Ptolemaic majors by degree with orbs — a Western construction, not Vedic graha dṛṣṭi.",
- "items": {
- "properties": {
- "applying": {
- "type": "boolean"
- },
- "orb": {
- "type": "number"
- },
- "planet1": {
- "type": "string"
- },
- "planet2": {
- "type": "string"
- },
- "type": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "computationId": {
- "description": "SHA-256 of the inputs: identical inputs give the same id, and it never exposes the birth data.",
- "type": "string"
- },
- "dasha": {
- "properties": {
- "current": {
- "$ref": "#/$defs/CurrentDasha"
- },
- "timeline": {
- "items": {
- "$ref": "#/$defs/DashaPeriod"
- },
- "type": "array"
- }
- },
- "type": [
- "object",
- "null"
- ]
- },
- "divisionals": {
- "description": "The vargas requested (default D9 and D10).",
- "items": {
- "$ref": "#/$defs/DivisionalChart"
- },
- "type": "array"
- },
- "domain": {
- "const": "core_chart",
- "type": "string"
- },
- "houses": {
- "items": {
- "$ref": "#/$defs/House"
- },
- "type": "array"
- },
- "planets": {
- "items": {
- "$ref": "#/$defs/Planet"
- },
- "type": "array"
- },
- "relocation": {
- "additionalProperties": true,
- "description": "Present when `location` was sent: this chart's own frame recomputed for that place.",
- "type": "object"
- },
- "western": {
- "additionalProperties": true,
- "description": "Modern Western techniques, published alongside the Jyotiṣa engine and not part of it. Every object carries `tradition: \"western\"` and `classical: false`.",
- "type": "object"
- },
- "yogas": {
- "items": {
- "$ref": "#/$defs/Yoga"
- },
- "type": "array"
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "ascendant": {
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "nakshatra": {
+ "description": "Nakṣatra of the sidereal ascendant.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pada": {
+ "description": "Pada (1–4) of the ascendant's nakṣatra.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "sign": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "aspects": {
+ "description": "The five Ptolemaic majors by degree with orbs — a Western construction, not Vedic graha dṛṣṭi.",
+ "items": {
+ "properties": {
+ "applying": {
+ "type": "boolean"
+ },
+ "orb": {
+ "type": "number"
+ },
+ "planet1": {
+ "type": "string"
+ },
+ "planet2": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "computationId": {
+ "description": "SHA-256 of every input that changes the result (birth date, time, coordinates, timezone, frame, daśā switch and depth, divisionals): identical inputs give the same id, different requests never share one, and it never exposes the birth data.",
+ "type": "string"
+ },
+ "dasha": {
+ "properties": {
+ "current": {
+ "$ref": "#/$defs/CurrentDasha"
+ },
+ "timeline": {
+ "items": {
+ "$ref": "#/$defs/DashaPeriod"
+ },
+ "type": "array"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "divisionals": {
+ "description": "The vargas requested (default D9 and D10).",
+ "items": {
+ "$ref": "#/$defs/DivisionalChart"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "const": "core_chart",
+ "type": "string"
+ },
+ "houses": {
+ "items": {
+ "$ref": "#/$defs/House"
+ },
+ "type": "array"
+ },
+ "planets": {
+ "items": {
+ "$ref": "#/$defs/Planet"
+ },
+ "type": "array"
+ },
+ "relocation": {
+ "additionalProperties": true,
+ "description": "Present when `location` was sent: this chart's own frame recomputed for that place.",
+ "type": "object"
+ },
+ "western": {
+ "additionalProperties": true,
+ "description": "Modern Western techniques, published alongside the Jyotiṣa engine and not part of it. Every object carries `tradition: \"western\"` and `classical: false`.",
+ "type": "object"
+ },
+ "yogas": {
+ "items": {
+ "$ref": "#/$defs/Yoga"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+]Output schema / $defs / Planet / properties / combustAdded value: +{
+ "description": "Combustion (astaṅgata): true when the graha is within its orb of the Sun (Moon 12°, Mars 17°, Mercury 14° or 12° retrograde, Jupiter 11°, Venus 10° or 8° retrograde, Saturn 15°). null where it does not apply: the Sun, Rahu, Ketu and the outer planets. Natal chart only; divisional planets omit it.",
+ "type": [
+ "boolean",
+ "null"
+ ]
+}Output schema / $defs / Planet / properties / combustionAdded value: +{
+ "description": "Present only when `combust` is true.",
+ "properties": {
+ "deep": {
+ "description": "Within half the orb.",
+ "type": "boolean"
+ },
+ "distanceFromSun": {
+ "description": "Angular distance from the Sun, degrees.",
+ "type": "number"
+ },
+ "orb": {
+ "description": "The combustion orb applied, degrees.",
+ "type": "number"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}get_techniquesresolve_timing3 fields changedInput schema / properties / dateRange / descriptionPrevious value: -"Optional period the decision is about: start and end dates, YYYY-MM-DD."New value: +"Optional period the decision is about: start and end dates, YYYY-MM-DD. The verdict is read at `start`; `end` must not precede it."Input schema / properties / targetDate / descriptionPrevious value: -"Optional date the decision is about, YYYY-MM-DD."New value: +"Optional date the decision is about, YYYY-MM-DD. The verdict is read at this day. Takes precedence over `dateRange`."Output schema / $defs / TimingResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/ForecastResponse"
- },
- {
- "properties": {
- "decisionQuestion": {
- "type": "string"
- },
- "exactDateAssessment": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/ForecastResponse"
+ },
+ {
+ "properties": {
+ "decisionQuestion": {
+ "type": "string"
+ },
+ "exactDateAssessment": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "referenceDate": {
+ "description": "The day the verdict, the daśā reading and eventTiming are anchored to: `targetDate` when sent, else `dateRange.start`, else the day of the call.",
+ "format": "date",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+]get_guna_milan1 field changedOutput schema / $defs / GunaMilanResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "gunaMilan": {
- "description": "Aṣṭakūṭa (36-point) matching.",
- "properties": {
- "bhakootDosha": {
- "$ref": "#/$defs/Dosha"
- },
- "interpretation": {
- "type": "string"
- },
- "kutas": {
- "items": {
- "properties": {
- "max": {
- "type": "number"
- },
- "name": {
- "type": "string"
- },
- "note": {
- "type": "string"
- },
- "score": {
- "type": "number"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "nadiDosha": {
- "$ref": "#/$defs/Dosha"
- },
- "totalGunas": {
- "type": "number"
- }
- },
- "type": "object"
- },
- "manglik": {
- "properties": {
- "a": {
- "$ref": "#/$defs/Manglik"
- },
- "b": {
- "$ref": "#/$defs/Manglik"
- },
- "cancelled": {
- "description": "True when the doṣa is neutralised across the pair (both Manglik, or the one present is self-mitigated).",
- "type": "boolean"
- },
- "reason": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "note": {
- "type": "string"
- },
- "partners": {
- "properties": {
- "a": {
- "properties": {
- "birth": {
- "type": "string"
- },
- "moonNakshatra": {
- "type": "string"
- },
- "moonSign": {
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "b": {
- "properties": {
- "birth": {
- "type": "string"
- },
- "moonNakshatra": {
- "type": "string"
- },
- "moonSign": {
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "type": "object"
- },
- "roles": {
- "description": "Which partner was read as the groom (Varṇa is counted from the groom).",
- "properties": {
- "basis": {
- "type": "string"
- },
- "bride": {
- "enum": [
- "a",
- "b"
- ],
- "type": "string"
- },
- "groom": {
- "enum": [
- "a",
- "b"
- ],
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "gunaMilan",
- "manglik"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "gunaMilan": {
+ "description": "Aṣṭakūṭa (36-point) matching.",
+ "properties": {
+ "bhakootDosha": {
+ "$ref": "#/$defs/Dosha"
+ },
+ "interpretation": {
+ "type": "string"
+ },
+ "kutas": {
+ "items": {
+ "properties": {
+ "max": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nadiDosha": {
+ "$ref": "#/$defs/Dosha"
+ },
+ "totalGunas": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "manglik": {
+ "properties": {
+ "a": {
+ "$ref": "#/$defs/Manglik"
+ },
+ "b": {
+ "$ref": "#/$defs/Manglik"
+ },
+ "cancelled": {
+ "description": "True when the doṣa is neutralised across the pair (both Manglik, or the one present is self-mitigated).",
+ "type": "boolean"
+ },
+ "points": {
+ "description": "The graded Kuja doṣa comparison (Trivedi's method, Raman's points table, reckoned from the lagna): a weighing of how evenly the two charts carry the doṣa — never a cancellation. variation = |A − B| ÷ the smaller total (null when one chart carries none and the other some); balanced = variation ≤ 0.25 (Raman). Symmetric: no gendered threshold.",
+ "nullable": true,
+ "properties": {
+ "balanced": {
+ "type": "boolean"
+ },
+ "heavier": {
+ "enum": [
+ "A",
+ "B"
+ ],
+ "nullable": true,
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "variation": {
+ "example": 0.5,
+ "nullable": true,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "pointsTotals": {
+ "description": "Each chart's Kuja points total (lagna reckoning).",
+ "nullable": true,
+ "properties": {
+ "a": {
+ "nullable": true,
+ "type": "number"
+ },
+ "b": {
+ "nullable": true,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "partners": {
+ "properties": {
+ "a": {
+ "properties": {
+ "birth": {
+ "type": "string"
+ },
+ "moonNakshatra": {
+ "type": "string"
+ },
+ "moonSign": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "b": {
+ "properties": {
+ "birth": {
+ "type": "string"
+ },
+ "moonNakshatra": {
+ "type": "string"
+ },
+ "moonSign": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "roles": {
+ "description": "Which partner was read as the groom (Varṇa is counted from the groom).",
+ "properties": {
+ "basis": {
+ "type": "string"
+ },
+ "bride": {
+ "enum": [
+ "a",
+ "b"
+ ],
+ "type": "string"
+ },
+ "groom": {
+ "enum": [
+ "a",
+ "b"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "gunaMilan",
+ "manglik"
+ ],
+ "type": "object"
+ }
+]get_guna_milan3 fields changedOutput schema / $defs / Manglik / descriptionPrevious value: -"Manglik (Kuja doṣa) for one chart, reckoned from the lagna, the Moon and Venus. A reckoning with house null was not computed — never read it as clean."New value: +"Manglik (Kuja doṣa) for one chart, reckoned from the lagna, the Moon and Venus. A reckoning with house null was not computed — never read it as clean. Classical exceptions are applied and named: whole-chart ones in cancelledBy (Mars in Leo or Aquarius; in its own sign or exalted, or exalted in the navāṁśa; conjunct Jupiter or the Moon; Jupiter or Venus in the ascendant), per-house ones on the reckoning as exemptBy."Output schema / $defs / Manglik / properties / cancelledByAdded value: +{
+ "description": "Classical exceptions (parihāra) that cancel the doṣa for this chart, each with the texts that state it. When any applies, present is false — the reckonings still show where Mars stands.",
+ "items": {
+ "properties": {
+ "rule": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / $defs / Manglik / properties / reckonings / items / properties / exemptByAdded value: +{
+ "description": "Set when Mars stands in a doṣa house but its sign exempts it there (2nd Gemini/Virgo, 4th Aries/Scorpio, 7th Capricorn/Cancer, 8th Sagittarius/Pisces, 12th Taurus/Libra) — the stated reason, with its sources.",
+ "type": "string"
+}get_domain_timeline1 field changedOutput schema / $defs / DomainTimelineResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "area": {
- "description": "The life area: what governs it, and every period (within the window, if one was given).",
- "properties": {
- "about": {
- "type": "string"
- },
- "governedBy": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "key": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "next": {
- "type": [
- "string",
- "null"
- ]
- },
- "now": {
- "type": [
- "string",
- "null"
- ]
- },
- "periods": {
- "items": {
- "properties": {
- "ageFrom": {
- "type": "integer"
- },
- "ageTo": {
- "type": "integer"
- },
- "because": {
- "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "chain": {
- "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
- "type": "string"
- },
- "focus": {
- "description": "primary: the area is in focus (the period lord rules or occupies the area's primary house, or is its kāraka; a node acts for its sign lord). also: the period only touches the area through a wider significator. `now`, `next` and the summary use primary periods only.",
- "enum": [
- "primary",
- "also"
- ],
- "type": "string"
- },
- "from": {
- "type": "string"
- },
- "lord": {
- "type": "string"
- },
- "past": {
- "type": "boolean"
- },
- "runningNow": {
- "type": "boolean"
- },
- "to": {
- "type": "string"
- },
- "words": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "shownFromAge": {
- "description": "Periods before this age are not shown for the area.",
- "type": "integer"
- }
- },
- "type": "object"
- },
- "domain": {
- "const": "domain_timeline",
- "type": "string"
- },
- "window": {
- "description": "The window asked for, or null for the whole life.",
- "properties": {
- "from": {
- "type": "string"
- },
- "to": {
- "type": "string"
- }
- },
- "type": [
- "object",
- "null"
- ]
- }
- },
- "required": [
- "area"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "area": {
+ "description": "The life area: what governs it, and every period (within the window, if one was given).",
+ "properties": {
+ "about": {
+ "type": "string"
+ },
+ "governedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "key": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "next": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "now": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periods": {
+ "items": {
+ "properties": {
+ "ageFrom": {
+ "type": "integer"
+ },
+ "ageTo": {
+ "type": "integer"
+ },
+ "because": {
+ "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "care": {
+ "description": "Health only, in-focus periods only: the body areas the tradition links to the period and the matching check-up. Not repeated in `words`.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "chain": {
+ "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
+ "type": "string"
+ },
+ "classical": {
+ "description": "The classical grounds behind the period, in plain words: the chapter (mahādaśā) lord, the period lord's nakṣatra (star) lord and its full aspect, where they bear on this area. Not repeated in `words`.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "focus": {
+ "description": "primary: the area is in focus (the period lord rules or occupies the area's primary house, or is its kāraka; a node acts for its sign lord). also: the period only touches the area through a wider significator. `now`, `next` and the summary use primary periods only.",
+ "enum": [
+ "primary",
+ "also"
+ ],
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "lord": {
+ "type": "string"
+ },
+ "past": {
+ "type": "boolean"
+ },
+ "runningNow": {
+ "type": "boolean"
+ },
+ "to": {
+ "type": "string"
+ },
+ "words": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "shownFromAge": {
+ "description": "Periods before this age are not shown for the area.",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "domain": {
+ "const": "domain_timeline",
+ "type": "string"
+ },
+ "window": {
+ "description": "The window asked for, or null for the whole life.",
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "area"
+ ],
+ "type": "object"
+ }
+]get_life_reading1 field changedOutput schema / $defs / LifeReadingResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "areas": {
- "description": "Eleven life areas, each with what governs it and every period, past and future.",
- "items": {
- "properties": {
- "about": {
- "type": "string"
- },
- "classicalSources": {
- "description": "Titles of the classical books the area draws on.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "governedBy": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "key": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "next": {
- "type": [
- "string",
- "null"
- ]
- },
- "now": {
- "type": [
- "string",
- "null"
- ]
- },
- "periods": {
- "items": {
- "properties": {
- "ageFrom": {
- "type": "integer"
- },
- "ageTo": {
- "type": "integer"
- },
- "because": {
- "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "chain": {
- "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
- "type": "string"
- },
- "focus": {
- "description": "primary: the area is in focus (the period lord rules or occupies the area's primary house, or is its kāraka; a node acts for its sign lord). also: the period only touches the area through a wider significator. `now`, `next` and the summary use primary periods only.",
- "enum": [
- "primary",
- "also"
- ],
- "type": "string"
- },
- "from": {
- "type": "string"
- },
- "lord": {
- "type": "string"
- },
- "past": {
- "type": "boolean"
- },
- "runningNow": {
- "type": "boolean"
- },
- "to": {
- "type": "string"
- },
- "words": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "shownFromAge": {
- "description": "Periods before this age are not shown for the area.",
- "type": "integer"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "chapters": {
- "description": "The life's chapters: each mahādaśā with its dates, ages and what it stands for.",
- "items": {
- "properties": {
- "ageFrom": {
- "type": "integer"
- },
- "ageTo": {
- "type": "integer"
- },
- "from": {
- "type": "string"
- },
- "lord": {
- "type": "string"
- },
- "past": {
- "type": "boolean"
- },
- "runningNow": {
- "type": "boolean"
- },
- "to": {
- "type": "string"
- },
- "words": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "domain": {
- "const": "life_reading",
- "type": "string"
- },
- "horizon": {
- "properties": {
- "until": {
- "type": "string"
- },
- "years": {
- "type": "number"
- }
- },
- "type": "object"
- },
- "recorded": {
- "description": "Your recorded events, each with the chapter and period running when it happened and the areas it belongs to.",
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- "summary": {
- "description": "Where the life stands now, in everyday words.",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "chapters",
- "areas"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "areas": {
+ "description": "Eleven life areas, each with what governs it and every period, past and future.",
+ "items": {
+ "properties": {
+ "about": {
+ "type": "string"
+ },
+ "classicalSources": {
+ "description": "Titles of the classical books the area draws on.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "governedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "key": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "next": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "now": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periods": {
+ "items": {
+ "properties": {
+ "ageFrom": {
+ "type": "integer"
+ },
+ "ageTo": {
+ "type": "integer"
+ },
+ "because": {
+ "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "care": {
+ "description": "Health only, in-focus periods only: the body areas the tradition links to the period and the matching check-up. Not repeated in `words`.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "chain": {
+ "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
+ "type": "string"
+ },
+ "classical": {
+ "description": "The classical grounds behind the period, in plain words: the chapter (mahādaśā) lord, the period lord's nakṣatra (star) lord and its full aspect, where they bear on this area. Not repeated in `words`.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "focus": {
+ "description": "primary: the area is in focus (the period lord rules or occupies the area's primary house, or is its kāraka; a node acts for its sign lord). also: the period only touches the area through a wider significator. `now`, `next` and the summary use primary periods only.",
+ "enum": [
+ "primary",
+ "also"
+ ],
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "lord": {
+ "type": "string"
+ },
+ "past": {
+ "type": "boolean"
+ },
+ "runningNow": {
+ "type": "boolean"
+ },
+ "to": {
+ "type": "string"
+ },
+ "words": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "shownFromAge": {
+ "description": "Periods before this age are not shown for the area.",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "chapters": {
+ "description": "The life's chapters: each mahādaśā with its dates, ages and what it stands for.",
+ "items": {
+ "properties": {
+ "ageFrom": {
+ "type": "integer"
+ },
+ "ageTo": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "lord": {
+ "type": "string"
+ },
+ "past": {
+ "type": "boolean"
+ },
+ "runningNow": {
+ "type": "boolean"
+ },
+ "to": {
+ "type": "string"
+ },
+ "words": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "const": "life_reading",
+ "type": "string"
+ },
+ "horizon": {
+ "properties": {
+ "until": {
+ "type": "string"
+ },
+ "years": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "recorded": {
+ "description": "Your recorded events, each with the chapter and period running when it happened and the areas it belongs to.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "description": "Where the life stands now, in everyday words.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "chapters",
+ "areas"
+ ],
+ "type": "object"
+ }
+]get_domain_timeline1 field changedOutput schema / $defs / DomainTimelineResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "area": {
- "description": "The life area: what governs it, and every period (within the window, if one was given).",
- "properties": {
- "about": {
- "type": "string"
- },
- "governedBy": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "key": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "next": {
- "type": [
- "string",
- "null"
- ]
- },
- "now": {
- "type": [
- "string",
- "null"
- ]
- },
- "periods": {
- "items": {
- "properties": {
- "ageFrom": {
- "type": "integer"
- },
- "ageTo": {
- "type": "integer"
- },
- "because": {
- "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "chain": {
- "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
- "type": "string"
- },
- "from": {
- "type": "string"
- },
- "lord": {
- "type": "string"
- },
- "past": {
- "type": "boolean"
- },
- "runningNow": {
- "type": "boolean"
- },
- "to": {
- "type": "string"
- },
- "words": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "shownFromAge": {
- "description": "Periods before this age are not shown for the area.",
- "type": "integer"
- }
- },
- "type": "object"
- },
- "domain": {
- "const": "domain_timeline",
- "type": "string"
- },
- "window": {
- "description": "The window asked for, or null for the whole life.",
- "properties": {
- "from": {
- "type": "string"
- },
- "to": {
- "type": "string"
- }
- },
- "type": [
- "object",
- "null"
- ]
- }
- },
- "required": [
- "area"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "area": {
+ "description": "The life area: what governs it, and every period (within the window, if one was given).",
+ "properties": {
+ "about": {
+ "type": "string"
+ },
+ "governedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "key": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "next": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "now": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periods": {
+ "items": {
+ "properties": {
+ "ageFrom": {
+ "type": "integer"
+ },
+ "ageTo": {
+ "type": "integer"
+ },
+ "because": {
+ "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "chain": {
+ "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
+ "type": "string"
+ },
+ "focus": {
+ "description": "primary: the area is in focus (the period lord rules or occupies the area's primary house, or is its kāraka; a node acts for its sign lord). also: the period only touches the area through a wider significator. `now`, `next` and the summary use primary periods only.",
+ "enum": [
+ "primary",
+ "also"
+ ],
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "lord": {
+ "type": "string"
+ },
+ "past": {
+ "type": "boolean"
+ },
+ "runningNow": {
+ "type": "boolean"
+ },
+ "to": {
+ "type": "string"
+ },
+ "words": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "shownFromAge": {
+ "description": "Periods before this age are not shown for the area.",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "domain": {
+ "const": "domain_timeline",
+ "type": "string"
+ },
+ "window": {
+ "description": "The window asked for, or null for the whole life.",
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "area"
+ ],
+ "type": "object"
+ }
+]get_life_reading1 field changedOutput schema / $defs / LifeReadingResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "areas": {
- "description": "Eleven life areas, each with what governs it and every period, past and future.",
- "items": {
- "properties": {
- "about": {
- "type": "string"
- },
- "classicalSources": {
- "description": "Titles of the classical books the area draws on.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "governedBy": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "key": {
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "next": {
- "type": [
- "string",
- "null"
- ]
- },
- "now": {
- "type": [
- "string",
- "null"
- ]
- },
- "periods": {
- "items": {
- "properties": {
- "ageFrom": {
- "type": "integer"
- },
- "ageTo": {
- "type": "integer"
- },
- "because": {
- "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "chain": {
- "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
- "type": "string"
- },
- "from": {
- "type": "string"
- },
- "lord": {
- "type": "string"
- },
- "past": {
- "type": "boolean"
- },
- "runningNow": {
- "type": "boolean"
- },
- "to": {
- "type": "string"
- },
- "words": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "shownFromAge": {
- "description": "Periods before this age are not shown for the area.",
- "type": "integer"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "chapters": {
- "description": "The life's chapters: each mahādaśā with its dates, ages and what it stands for.",
- "items": {
- "properties": {
- "ageFrom": {
- "type": "integer"
- },
- "ageTo": {
- "type": "integer"
- },
- "from": {
- "type": "string"
- },
- "lord": {
- "type": "string"
- },
- "past": {
- "type": "boolean"
- },
- "runningNow": {
- "type": "boolean"
- },
- "to": {
- "type": "string"
- },
- "words": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "domain": {
- "const": "life_reading",
- "type": "string"
- },
- "horizon": {
- "properties": {
- "until": {
- "type": "string"
- },
- "years": {
- "type": "number"
- }
- },
- "type": "object"
- },
- "recorded": {
- "description": "Your recorded events, each with the chapter and period running when it happened and the areas it belongs to.",
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- "summary": {
- "description": "Where the life stands now, in everyday words.",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "chapters",
- "areas"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "areas": {
+ "description": "Eleven life areas, each with what governs it and every period, past and future.",
+ "items": {
+ "properties": {
+ "about": {
+ "type": "string"
+ },
+ "classicalSources": {
+ "description": "Titles of the classical books the area draws on.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "governedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "key": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "next": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "now": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periods": {
+ "items": {
+ "properties": {
+ "ageFrom": {
+ "type": "integer"
+ },
+ "ageTo": {
+ "type": "integer"
+ },
+ "because": {
+ "description": "Why this planet governs the area on this chart, e.g. \"lord of the 7th\".",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "chain": {
+ "description": "Mahādaśā / antardaśā, e.g. \"Saturn / Venus\".",
+ "type": "string"
+ },
+ "focus": {
+ "description": "primary: the area is in focus (the period lord rules or occupies the area's primary house, or is its kāraka; a node acts for its sign lord). also: the period only touches the area through a wider significator. `now`, `next` and the summary use primary periods only.",
+ "enum": [
+ "primary",
+ "also"
+ ],
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "lord": {
+ "type": "string"
+ },
+ "past": {
+ "type": "boolean"
+ },
+ "runningNow": {
+ "type": "boolean"
+ },
+ "to": {
+ "type": "string"
+ },
+ "words": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "shownFromAge": {
+ "description": "Periods before this age are not shown for the area.",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "chapters": {
+ "description": "The life's chapters: each mahādaśā with its dates, ages and what it stands for.",
+ "items": {
+ "properties": {
+ "ageFrom": {
+ "type": "integer"
+ },
+ "ageTo": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "lord": {
+ "type": "string"
+ },
+ "past": {
+ "type": "boolean"
+ },
+ "runningNow": {
+ "type": "boolean"
+ },
+ "to": {
+ "type": "string"
+ },
+ "words": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "const": "life_reading",
+ "type": "string"
+ },
+ "horizon": {
+ "properties": {
+ "until": {
+ "type": "string"
+ },
+ "years": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "recorded": {
+ "description": "Your recorded events, each with the chapter and period running when it happened and the areas it belongs to.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "description": "Where the life stands now, in everyday words.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "chapters",
+ "areas"
+ ],
+ "type": "object"
+ }
+]assess_gemstoneget_chart2 fields changedOutput schema / $defs / ChartResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "ascendant": {
- "properties": {
- "degree": {
- "type": "number"
- },
- "nakshatra": {
- "type": [
- "string",
- "null"
- ]
- },
- "sign": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "aspects": {
- "description": "The five Ptolemaic majors by degree with orbs — a Western construction, not Vedic graha dṛṣṭi.",
- "items": {
- "properties": {
- "applying": {
- "type": "boolean"
- },
- "orb": {
- "type": "number"
- },
- "planet1": {
- "type": "string"
- },
- "planet2": {
- "type": "string"
- },
- "type": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "computationId": {
- "description": "SHA-256 of the inputs: identical inputs give the same id, and it never exposes the birth data.",
- "type": "string"
- },
- "dasha": {
- "properties": {
- "current": {
- "$ref": "#/$defs/CurrentDasha"
- },
- "timeline": {
- "items": {
- "$ref": "#/$defs/DashaPeriod"
- },
- "type": "array"
- }
- },
- "type": [
- "object",
- "null"
- ]
- },
- "divisionals": {
- "description": "The vargas requested (default D9 and D10).",
- "items": {
- "$ref": "#/$defs/DivisionalChart"
- },
- "type": "array"
- },
- "domain": {
- "const": "core_chart",
- "type": "string"
- },
- "houses": {
- "items": {
- "$ref": "#/$defs/House"
- },
- "type": "array"
- },
- "planets": {
- "items": {
- "$ref": "#/$defs/Planet"
- },
- "type": "array"
- },
- "relocation": {
- "additionalProperties": true,
- "description": "Present when `location` was sent: this chart's own frame recomputed for that place.",
- "type": "object"
- },
- "western": {
- "additionalProperties": true,
- "description": "Modern Western techniques, published alongside the Jyotiṣa engine and not part of it. Every object carries `tradition: \"western\"` and `classical: false`.",
- "type": "object"
- },
- "yogas": {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "ascendant": {
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "nakshatra": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sign": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "aspects": {
+ "description": "The five Ptolemaic majors by degree with orbs — a Western construction, not Vedic graha dṛṣṭi.",
+ "items": {
+ "properties": {
+ "applying": {
+ "type": "boolean"
+ },
+ "orb": {
+ "type": "number"
+ },
+ "planet1": {
+ "type": "string"
+ },
+ "planet2": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "computationId": {
+ "description": "SHA-256 of the inputs: identical inputs give the same id, and it never exposes the birth data.",
+ "type": "string"
+ },
+ "dasha": {
+ "properties": {
+ "current": {
+ "$ref": "#/$defs/CurrentDasha"
+ },
+ "timeline": {
+ "items": {
+ "$ref": "#/$defs/DashaPeriod"
+ },
+ "type": "array"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "divisionals": {
+ "description": "The vargas requested (default D9 and D10).",
+ "items": {
+ "$ref": "#/$defs/DivisionalChart"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "const": "core_chart",
+ "type": "string"
+ },
+ "houses": {
+ "items": {
+ "$ref": "#/$defs/House"
+ },
+ "type": "array"
+ },
+ "planets": {
+ "items": {
+ "$ref": "#/$defs/Planet"
+ },
+ "type": "array"
+ },
+ "relocation": {
+ "additionalProperties": true,
+ "description": "Present when `location` was sent: this chart's own frame recomputed for that place.",
+ "type": "object"
+ },
+ "western": {
+ "additionalProperties": true,
+ "description": "Modern Western techniques, published alongside the Jyotiṣa engine and not part of it. Every object carries `tradition: \"western\"` and `classical: false`.",
+ "type": "object"
+ },
+ "yogas": {
+ "items": {
+ "$ref": "#/$defs/Yoga"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+]Output schema / $defs / YogaAdded value: +{
+ "description": "A yoga formed in this chart. AstroNest does not rank yogas: there is no strength or score, only whether it is formed and what it rests on.",
+ "properties": {
+ "basis": {
+ "description": "What the yoga rests on in this chart, e.g. \"Jupiter and Moon in kendra from each other\".",
+ "type": "string"
+ },
+ "classicalSource": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "englishName": {
+ "type": "string"
+ },
+ "houses": {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "planets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "strength": {
+ "deprecated": true,
+ "description": "Always null: AstroNest does not rank yogas. Read basis instead.",
+ "enum": [
+ "strong",
+ "moderate",
+ "weak",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_domain_timelineget_life_readingget_relationship_readingget_venture_timingget_chart6 fields changedInput schema / properties / divisionalsAdded value: +{
+ "default": [
+ "d9",
+ "d10"
+ ],
+ "description": "Divisional charts (vargas) to include: any of the sixteen ṣoḍaśavarga. Default d9 (navāṁśa) and d10 (daśāṁśa); send [] for none. Each returns its ascendant and every graha's sign, degree and house within the varga, by the Parāśari formulas.",
+ "items": {
+ "enum": [
+ "d1",
+ "d2",
+ "d3",
+ "d4",
+ "d7",
+ "d9",
+ "d10",
+ "d12",
+ "d16",
+ "d20",
+ "d24",
+ "d27",
+ "d30",
+ "d40",
+ "d45",
+ "d60"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / $defs / ChartResponse / allOfPrevious value: -[
- {
- "$ref": "#/$defs/Envelope"
- },
- {
- "properties": {
- "ascendant": {
- "properties": {
- "degree": {
- "type": "number"
- },
- "nakshatra": {
- "type": [
- "string",
- "null"
- ]
- },
- "sign": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "aspects": {
- "description": "The five Ptolemaic majors by degree with orbs — a Western construction, not Vedic graha dṛṣṭi.",
- "items": {
- "properties": {
- "applying": {
- "type": "boolean"
- },
- "orb": {
- "type": "number"
- },
- "planet1": {
- "type": "string"
- },
- "planet2": {
- "type": "string"
- },
- "type": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- "computationId": {
- "description": "SHA-256 of the inputs: identical inputs give the same id, and it never exposes the birth data.",
- "type": "string"
- },
- "dasha": {
- "properties": {
- "current": {
- "$ref": "#/$defs/CurrentDasha"
- },
- "timeline": {
- "items": {
- "$ref": "#/$defs/DashaPeriod"
- },
- "type": "array"
- }
- },
- "type": [
- "object",
- "null"
- ]
- },
- "divisionals": {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- "domain": {
- "const": "core_chart",
- "type": "string"
- },
- "houses": {
- "items": {
- "$ref": "#/$defs/House"
- },
- "type": "array"
- },
- "planets": {
- "items": {
- "$ref": "#/$defs/Planet"
- },
- "type": "array"
- },
- "relocation": {
- "additionalProperties": true,
- "description": "Present when `location` was sent: this chart's own frame recomputed for that place.",
- "type": "object"
- },
- "western": {
- "additionalProperties": true,
- "description": "Modern Western techniques, published alongside the Jyotiṣa engine and not part of it. Every object carries `tradition: \"western\"` and `classical: false`.",
- "type": "object"
- },
- "yogas": {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/Envelope"
+ },
+ {
+ "properties": {
+ "ascendant": {
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "nakshatra": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sign": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "aspects": {
+ "description": "The five Ptolemaic majors by degree with orbs — a Western construction, not Vedic graha dṛṣṭi.",
+ "items": {
+ "properties": {
+ "applying": {
+ "type": "boolean"
+ },
+ "orb": {
+ "type": "number"
+ },
+ "planet1": {
+ "type": "string"
+ },
+ "planet2": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "computationId": {
+ "description": "SHA-256 of the inputs: identical inputs give the same id, and it never exposes the birth data.",
+ "type": "string"
+ },
+ "dasha": {
+ "properties": {
+ "current": {
+ "$ref": "#/$defs/CurrentDasha"
+ },
+ "timeline": {
+ "items": {
+ "$ref": "#/$defs/DashaPeriod"
+ },
+ "type": "array"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "divisionals": {
+ "description": "The vargas requested (default D9 and D10).",
+ "items": {
+ "$ref": "#/$defs/DivisionalChart"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "const": "core_chart",
+ "type": "string"
+ },
+ "houses": {
+ "items": {
+ "$ref": "#/$defs/House"
+ },
+ "type": "array"
+ },
+ "planets": {
+ "items": {
+ "$ref": "#/$defs/Planet"
+ },
+ "type": "array"
+ },
+ "relocation": {
+ "additionalProperties": true,
+ "description": "Present when `location` was sent: this chart's own frame recomputed for that place.",
+ "type": "object"
+ },
+ "western": {
+ "additionalProperties": true,
+ "description": "Modern Western techniques, published alongside the Jyotiṣa engine and not part of it. Every object carries `tradition: \"western\"` and `classical: false`.",
+ "type": "object"
+ },
+ "yogas": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+]Output schema / $defs / CurrentDasha / properties / pratyantardashaAdded value: +{
+ "description": "The running pratyantardaśā.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / CurrentDasha / properties / pratyantardashaEndAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / DashaPeriod / properties / pratyantardashasAdded value: +{
+ "description": "On each antardaśā when depth is 'pratyantardasha'.",
+ "items": {
+ "$ref": "#/$defs/DashaPeriod"
+ },
+ "type": "array"
+}Output schema / $defs / DivisionalChartAdded value: +{
+ "description": "One varga. Houses count whole-sign from the varga ascendant. Nakṣatra, pada and dignity are natal concepts and are null here.",
+ "properties": {
+ "ascendant": {
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "sign": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "division": {
+ "description": "D9, D10, …",
+ "type": "string"
+ },
+ "planets": {
+ "items": {
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "dignity": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "house": {
+ "type": "integer"
+ },
+ "longitude": {
+ "type": "number"
+ },
+ "nakshatra": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pada": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "planet": {
+ "type": "string"
+ },
+ "retrograde": {
+ "type": "boolean"
+ },
+ "sign": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_dasha4 fields changedInput schema / properties / depthAdded value: +{
+ "default": "antardasha",
+ "description": "Timeline depth. 'pratyantardasha' nests the pratyantardaśās under each antardaśā (about ten times larger). The current periods always include the running pratyantardaśā.",
+ "enum": [
+ "antardasha",
+ "pratyantardasha"
+ ],
+ "type": "string"
+}Output schema / $defs / CurrentDasha / properties / pratyantardashaAdded value: +{
+ "description": "The running pratyantardaśā.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / CurrentDasha / properties / pratyantardashaEndAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / DashaPeriod / properties / pratyantardashasAdded value: +{
+ "description": "On each antardaśā when depth is 'pratyantardasha'.",
+ "items": {
+ "$ref": "#/$defs/DashaPeriod"
+ },
+ "type": "array"
+}get_guna_milanfind_muhurtaget_chartget_compatibilityget_dashaget_ephemeris_anglesget_ephemeris_ayanamsaget_ephemeris_positionsget_ephemeris_seriesget_ephemeris_sunriseget_forecastget_guidanceinterpret_domainresolve_timingVedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Vedic astrology for AI agents: chart facts, panchang windows, and Guna Milan compatibility.
Vedic kundli, panchang, dashas, nakshatras and KP charts for AI agents, one API key.
Vedic astrology from a real ephemeris: birth chart, life-event timing and Kundli matching.
Add one secure layer between your agents and this server.
