What can you do with this server?

Vedaksha is an MCP server for Vedic astrology and astronomical ephemeris computations. * Compute natal charts (kundali) with planets, houses/cusps, aspects, dignities, ayanamsha, and configurable house systems. * Compute dashas across eight systems, plus karakas, combustion, vargas, shadbala, ashtakavarga, bhavas, drishti, and gochara. * Compute panchanga limbs and search ranked muhurta windows. * Compute transits and transit–natal aspects, and search exact transit events over time ranges. * Compute synastry and composite charts from planet longitudes. * Emit chart property graphs as Cypher, SurrealQL, JSON-LD, JSON, or RAG embedding text. * Accept UT1 Julian Days and sidereal ayanamshas, with location, elevation, and timezone options where relevant.

Which integrations are available for this server?

Supports deployment to Cloudflare Workers edge computing platform using the AnalyticalProvider ephemeris for zero-data environments. Provides Docker container deployment for the MCP server with HTTP transport on port 3100. Supports macOS arm64 platform with pre-built Python wheels available via PyPI installation. Provides Python package distribution through PyPI for Python bindings installation and usage. Provides Python bindings via PyO3 for chart computation and Vedic astrology functionality. Provides native Rust crates for astronomical ephemeris computation and Vedic astrology platform functionality. Provides WebAssembly bindings for browser-based chart computation with 972KB binary and zero data files.

de en es ja ko ru zh

Vedaksha

by arthiqlabs

Overview Schema Source Related Servers Discussions Admin

Rust

Hybrid

Vedaksha: Rust ephemeris and Vedic astrology (Jyotish) engine

For developers building kundli (kundali) apps, panchang calendars and AI agents. Natal charts, dashas, vargas, shadbala and panchanga, computed from an ephemeris that agrees with JPL Horizons to 0.096″ mean in longitude, in Rust, Python and WebAssembly, and as 17 MCP tools. Clean-room: every algorithm is traced to a primary source. Source-available under BUSL-1.1, with no AGPL obligations; each release becomes Apache-2.0 four years after it ships.

crates.io docs.rs PyPI npm MSRV License

Website · Docs · Playground · API reference · Blog

clean-room · 0.096″ mean longitude vs JPL Horizons · 1,625 tests (per push) + 24,350 oracle rows · MCP-native · BUSL-1.1 → Apache 2.0

Install · Quick start · Accuracy · What's inside · MCP + property graph · Provenance · FAQ · License

Install

Platform	Install	Notes
Rust	`cargo add vedaksha`	full pipeline
Python	`pip install vedaksha`	engine via WebAssembly, `py3-none-any`, Python ≥ 3.9 — no Rust toolchain
WASM	`npm install vedaksha-wasm`	browser & edge, no data files
MCP	`cargo install vedaksha-mcp`	stdio + HTTP (bearer auth)
Docker	`docker run -e VEDAKSHA_MCP_TOKEN=… -p 3100:3100 ghcr.io/arthiqlabs/vedaksha-mcp`	multi-arch (amd64 + arm64)

Compute janam kundali (natal charts), panchanga, dashas, nakshatras, vargas, shadbala, ashtakavarga, muhurta and transits/gochara from a sub-arcsecond ephemeris (JPL DE440s/DE441, worst case 0.272″ against Horizons) or from the data-file-free VSOP87A + ELP/MPP02 series (mean 0.160″, worst case 1.473″ over 1900–2025).

flowchart LR
  K["JPL DE440s / DE441<br/>SPK kernel, ~31 MB"] --> E
  V["VSOP87A + ELP/MPP02<br/>compiled to constants,<br/>no data files"] --> E
  E["Ephemeris core<br/>precession · nutation<br/>light-time · deflection · ΔT"] --> W["Western<br/>houses · aspects<br/>dignities"]
  E --> J["Jyotish<br/>nakshatras · dashas · vargas<br/>panchanga · shadbala · muhurta"]
  W --> C["ComputedChart"]
  J --> C
  C --> G["Property graph<br/>Cypher · SurrealQL<br/>JSON-LD · RAG text"]
  C --> M["MCP server<br/>17 tools · stdio + HTTP"]
  C --> S["Rust · Python · WASM"]

Quick start

Python (pip install vedaksha): a sidereal (Lahiri) whole-sign chart, i.e. a kundli.

from vedaksha import Vedaksha

vk = Vedaksha()
chart = vk.natal_chart(julian_day=2451545.0, latitude=28.6139, longitude=77.2090,
                       ayanamsha="IndianOfficial", house_system="WholeSign")
print(chart["houses"]["asc"], [(p["name"], p["sign"]) for p in chart["planets"]])

Rust (cargo add vedaksha):

use vedaksha::prelude::*;

fn main() {
    // 2024-03-20 12:00 UT1. The day is a fraction: noon on the 20th is 20.5.
    let jd = calendar_to_jd(2024, 3, 20.5);
    let moon = apparent_position(&AnalyticalProvider, Body::Moon, jd).expect("in range");
    println!("Moon {:.4}°", moon.ecliptic.longitude.to_degrees());
}

A full chart, with houses and a sidereal zodiac, is the compiled doctest in crates/vedaksha/src/lib.rs.

JavaScript in the browser (npm install vedaksha-wasm; no data files):

import init, { compute_natal_chart } from "vedaksha-wasm";

await init();
const chart = JSON.parse(compute_natal_chart(JSON.stringify({
  year: 2024, month: 3, day: 20, hour: 12, minute: 0,   // UTC
  latitude: 28.6139, longitude: 77.2090,
  ayanamsha: "IndianOfficial", house_system: "WholeSign",
})));

MCP (Claude Desktop claude_desktop_config.json, Cursor .cursor/mcp.json, or any stdio MCP client):

{
  "mcpServers": {
    "vedaksha": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp", "--stdio"]
    }
  }
}

Without Docker, cargo install vedaksha-mcp and set "command": "vedaksha-mcp" with no arguments, or pip install vedaksha and use vedaksha-mcp the same way.

Every Julian Day on the public surfaces is UT1, not TT and not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 for Earth rotation, which fixes the ascendant, MC and all twelve cusps. Passing a TDB Julian Day adds ΔT worth of rotation instead of removing it — 0.289° (17.3′) at today's ΔT ≈ 69 s, on every cusp. Two exceptions say so in their names: the raw SPK query (state_vector), which indexes the kernel directly and takes TDB, and the Python binding's analytical_position(body, julian_day_tt), which takes TT.

Accuracy

These figures are reproducible, not just asserted: vedaksha-parity is a separate harness (maintained by the same authors as this engine) that anyone can run against their own copies of the reference kernels to check the published numbers below.

Every figure is printed by a named test. Reproduce the ephemeris tables with bash scripts/download_de440s.sh, then cargo test -p vedaksha-ephem-core --release -- --include-ignored --nocapture; the ayanamsha figures come from cargo test -p vedaksha-astro sidereal, and the cross-check against an independent Python derivation of the same primaries from cargo test -p vedaksha-astro --test ayanamsha_fixture.

What the headline 0.096″ measures — precisely. It is a mean apparent geocentric ecliptic-longitude residual, not a general position-accuracy figure: the fixture also carries ref_latitude, ref_distance and ref_speed, but oracle_comparison.rs marks them dead_code and none of the three enters this number. It covers the 1900–2025 rows, at 1,535 comparisons per body (15,350 total across 10 bodies). The full 1900–2100 grid of 24,350 rows has a mean of 0.088″ and the same worst row (see below); the 1900–2025 cut is kept so that the published count and definition do not change. And it compares against planetary-system barycentres, not physical planet centres, matching what the DE440s kernel stores and what SpkReader returns; querying centres instead would inject a spurious ~0.1″ offset for the outer planets (scripts/generate_horizons_oracle.py) — the same order of magnitude as the headline mean itself. These facts are also published as data in metrics.json's accuracy block (quantity, era, targetConvention), so the site renders them rather than anyone hand-copying this paragraph.

SpkReader vs JPL Horizons (DE441) — oracle_comparison.rs, 24,350 committed rows (10 bodies × 2,435 dates, 1900–2100). Horizons serves DE441, so this measures our DE440s pipeline against an independent kernel.

Era	Comparisons	Mean	Max
1900–2025	15,350	0.096″	0.272″ (Moon, 1962-01-06)
1900–2100 (all)	24,350	0.088″	0.272″ (Moon, 1962-01-06)

All 24,350 comparisons are within one arcsecond. Per body over 1900–2025 the mean runs from 0.092″ (Moon) to 0.100″ (Pluto), and the worst row of every body is between 0.243″ and 0.272″.

Time scale. Horizons' time tags are UT1 before 1962-01-20 and UTC from then. The oracle converts the UTC tags to TT with the leap-second count, as Horizons does itself, and reads the engine in TT, so neither ΔT nor UT1 − UTC is part of those rows' residual, and the oracle says nothing about ΔT there; earlier rows go through the engine's ΔT. Rows from 2026 on are compared the same way and are within 0.189″ (Moon, 2099-10-04). A Julian Day in UT1 after 2033.75 rests on an extrapolated ΔT (delta_t.rs), and one second of ΔT moves the Moon about 0.55″.

What the remaining 0.096″ is. After 1962 every body sits at 0.047″ to 0.054″ mean and at most 0.062″; before 1962 the bodies sit at 0.138″ to 0.146″ mean. That offset is shared by every body: it is the difference between Horizons' IAU 1976/1980 precession and nutation and the IAU 2006/2000B this engine uses. It is a difference of convention, and it is not emulated here. The largest row, the Moon on 1962-01-06, lies between 1962-01-01, where this engine hands ΔT from the SMH2016 spline to the USNO rows, and 1962-01-20, where Horizons switches from its pre-1962 series to its Earth-orientation file; the two series differ by 0.371 s across that handover, which is 0.2″ of Moon longitude (delta_t.rs). The Sun's light deflection of the planets is applied (solar_deflection_oracle.rs).

AnalyticalProvider vs JPL Horizons — analytical_oracle.rs, 1900–2025: overall mean 0.160″, worst case 1.473″ (Neptune, 2025-09-02), Moon 0.094″ mean via ELP/MPP02 (0.055″ after 1962). 13,815 comparisons across 9 bodies (1,535 dates per body) over 1900–2025; see metrics.json's accuracy.analytical block. The same run over all 21,915 comparisons to 2100 has a mean of 0.251″ and a worst case of 2.248″ (Neptune, 2078-01-27); metrics.json does not publish that pair.

Per body, because the mean hides a pattern worth knowing before you pick this provider:

body	mean″	body	mean″
Sun	0.094	Jupiter	0.148
Moon	0.094	Saturn	0.159
Mercury	0.094	Uranus	0.257
Venus	0.094	Neptune	0.410
Mars	0.090

The Sun, the Moon and the inner planets sit in a tight band at 0.090″ to 0.094″ and the error then grows outward. Split at 1962-01-20, all nine bodies sit at 0.131″ to 0.153″ mean before it, the same frame offset the SPK path shows. After it the Sun and the inner planets are at 0.038″ to 0.039″, the Moon at 0.055″, and Jupiter, Saturn, Uranus and Neptune at 0.165″, 0.165″, 0.365″ and 0.660″.

That growth belongs to the theory, not to how the tables are cut. scripts/generate_vsop87a.py drops terms below a uniform absolute amplitude of 1e-7 AU, but evaluating the complete untruncated VSOP87A series gives the same outer-planet residuals as the committed tables to four decimals (measured on geometric heliocentric vectors against DE440s over 1900–2100; the notes on VSOP87A_TO_EQUATORIAL in crates/vedaksha-ephem-core/src/analytical/mod.rs have the table). The authors fitted the theory to the JPL integration DE200, not to DE440 (vsop87.doc, "PRECISION"), and that is what the residual measures. If you need the outer planets to sub-0.1″, use SpkReader, where they are no worse than the inner bodies: Jupiter and Saturn are 0.096″ mean against the same oracle, inside the 0.092″ to 0.100″ band of every other body.

Until 2026-08-20 the analytical figures were an order of magnitude worse, and this README attributed the gap to VSOP87A being a truncated theory. That was wrong, and the wording protected a defect of ours: the analytical provider answered EarthMoonBarycenter with VSOP87A's Earth-centre series, so the observer sat 4,671 km off, and earth_state divided a barycentre-relative Moon by 1 + EMRAT instead of EMRAT for a further 56.8 km. Both are fixed; the figures before and after are in CHANGELOG-v6.1.0.md.

The SPK and analytical figures above are the v10.0.0 measurement, the same run that metrics.json and vedaksha.net/accuracy publish. The figures it replaced, and their causes, are in CHANGELOG-v10.0.0.md: ΔT read from the measurements and the published predictions, 30 corrected nutation rows, the Sun's light deflection of the planets, VSOP87A rotated by the matrix its authors publish, and an oracle that compares Horizons' UTC tags in TT. One body is worse at its maximum than before: analytical Uranus, now 1.201″, although its mean improved.

ELP/MPP02 Moon — lunar_horizons.rs: 0.015″ at J2000, 0.020–0.053″ across 1500–2500 CE.

What is not measured

House cusps are not validated against any external reference.
No ayanamsha is validated against another implementation, and that is deliberate. All eleven are derived forward from a primary — a chapter, a committee, a proposer's own paper, or a star catalogue — and each reproduces its own anchor to 1e-9° and, where its primary documents one, its own zero year. What is not claimed is agreement with anyone else's numbers: comparing against them would be the reverse-engineering this re-derivation exists to undo. See docs/audit/2026-08-17-ayanamsha-cleanroom/.
Dasha, nakshatra and shadbala tests check the text's own rules, not an external comparison: they verify that BPHS constants sum to 120 years, that boundaries tile the circle, and that shadbala parts come out as the verses' formulas give them when worked by hand. No dasha period or shadbala figure is compared with another implementation's output.
The library's coarse shadbala form is partial. compute_shadbala_full carries four of Sthana Bala's five parts (Uchcha, Ojhayugma, Kendradi and Drekkana, without Saptavargaja) and only Nathonnata and Paksha of Kala Bala, as 0-or-30 steps; its Cheshta, Dig and Drik grades are not the verses'. The complete form, compute_shadbala_complete (BPHS 27, part by part, with an option wherever the text leaves a parameter open), is what the MCP compute_shadbala tool and the WASM export serve.

Technical report

A full write-up of both ephemeris pipelines, their measured accuracy, and the clean-room provenance of every algorithm: docs/paper/main.tex (build with make -C docs/paper pdf, requires tectonic).

It goes well beyond the summary above, and reports several things that are stated nowhere else:

Cross-validation against two national-agency ephemerides, measured with a separate parity harness maintained by the same authors (not a third party), from two different agencies (JPL DE440 and IMCCE INPOP21a), rather than agreement with JPL alone.
Analytical-path accuracy across 1550–2650 CE, per body and per century-band of distance from J2000, with the time scale removed from the comparison by addressing both sides in TT so that ΔT divergence cannot contaminate the residual.
Component-level validation of the SPK reader against another implementation's read of a comparable kernel, isolating the DAF/SPK parser and Chebyshev evaluation from the apparent-place pipeline layered on top.
A methodological note on reproducibility: bit-level output is architecture-scoped, because the SIMD trigonometric kernel maps to one AVX2 register but two NEON registers. Accuracy is not — measured identical to a milliarcsecond on both. (Since v10.0.0 the lunar series alone no longer calls that kernel and is bit-identical on both architectures; the whole analytical provider still is not.)
What is not validated, stated plainly, including house cusps, the true node, and every ayanamsha.

Status: not peer reviewed, and not submitted anywhere. It is a technical report, not a preprint. Every measured figure in it is specific to the engine version named on its title page.

What's inside

Two ephemeris providers. SpkReader reads JPL DE440s (~31 MB) for sub-arcsecond work. AnalyticalProvider compiles VSOP87A + ELP/MPP02 to constants and needs no data files — for WASM, edge and Cloudflare Workers. ChebyshevProvider is an opt-in provider that fits the same series per segment with Chebyshev polynomials (within 0.1 m for the Moon and 3 m for a planet, over the whole range) for workloads that ask for many nearby times; AnalyticalProvider stays the exact series.

Speed. On one Apple M5 Pro (Criterion medians, v10.0.0): an analytical Moon in 56 µs, a nine-body apparent-place chart in 0.97 ms, the Sun in 2.9 µs; 3.3, 3.8 and 2.1 times v9.4.1. Twenty 30-day muhurta searches and five one-year transit scans over MCP take 0.46 s, where v9.4.1 took 17.5 s. The series are evaluated in full, and the one interpolated path (the walk the scans read) stays within 5e-5″ of the direct computation; how each was done, and the full table, are in CHANGELOG-v10.0.0.md.

Jyotish, from primary sources. 27 nakshatras with padas and lords · 8 dasha systems (Vimshottari, Ashtottari and Yogini, which runs beyond its first round; the rashi dashas Chara, Narayana, Sthira, Niryana Shoola and Maheshwara) · all 16 vargas (D-1 → D-60) · the complete shadbala of BPHS 27 with Ishta/Kashta phala, bhava bala (27.26 to 31) and vimshopaka bala (all four schemes) · 11 ayanamshas, each traceable to a chapter, a star or a committee · panchanga's five limbs, with vara reckoned from local sunrise and Rahu/Gulika Kalam as real time windows · graded and degree-wise (sputa) drishti per BPHS Ch. 26 · four upagrahas (Kala, Mrityu, Ardhaprahara, Yamaghantaka) · mean, true and osculating nodes, all referred to the ecliptic of date, with the J2000 variant tracking DE441's OM to 0.6″ (KP sub-lord ready).

Sky events, in the vedaksha-vedic crate. Solar and lunar eclipses, every sign ingress and retrograde station of a graha in a range, heliacal rising and setting by the Surya Siddhanta's kalamsha, amanta and purnimanta lunar months with adhika and kshaya, and tithi, nakshatra, karana and yoga ends and sankrantis timed to the resolution of a Julian Day. Long scans read the Moon and the Sun from an interpolated walk (walk::BodyWalk, vedaksha_vedic::walked::WalkedSky) within 5e-5″ for the Moon and 1e-5″ for the Sun of the direct computation; the planets are not walked.

Western: calculation, not interpretation. 10 house systems, major aspects with applying/separating motion, essential dignities, synastry and composite. ChartConfig defaults to tropical. There is no Western interpretive layer and no parity with the Jyotish surface.

Crates, published to crates.io in lockstep: vedaksha (umbrella, 7 locales) · -math · -ephem-core · -astro · -vedic · -graph · -mcp.

MCP + property graph

17 tools, discoverable with a single tools/list. The catalog is generated from the Rust definitions and locked by a snapshot test, so it cannot silently drift from the code. compute_dasha serves the eight dasha systems above. compute_shadbala takes a moment and a place (julian_day, latitude, longitude and a sidereal ayanamsha), casts the chart itself and returns every part of BPHS 27 for the seven grahas.

compute_natal_chart · compute_dasha · compute_vargas · compute_karakas · compute_combustion · compute_shadbala · compute_ashtakavarga · compute_transit · compute_gochara · search_transits · search_muhurta · compute_panchanga · compute_drishti · compute_bhavas · compute_synastry · compute_composite · emit_graph

Any chart converts to a property graph via emit_graph or vedaksha_graph::chart_to_graph, emitting Cypher, SurrealQL, JSON-LD, JSON or RAG embedding text. An agent can then ask "which planets aspect the 7th-house lord?" as a graph query instead of re-implementing chart logic. Computations themselves return typed structs; the graph is a projection you ask for.

What a chart actually yields: 4 of the ontology's 9 node types (Chart, Planet, Sign, House) and 7 of its 12 edge types. Nakshatra, Pada, Pattern, DashaPeriod and FixedStar are defined in vedaksha_graph::ontology but are not built from a ComputedChart, which does not carry the data they need. Compute those through their own APIs.

VEDAKSHA_MCP_TOKEN=… vedaksha-mcp --http --port 3100

HTTP mode requires Authorization: Bearer <token> on every POST and refuses to start without VEDAKSHA_MCP_TOKEN, unless you pass --insecure-no-auth for a trusted network. /health and the informational GET stay open.

Clean-room provenance

Every implemented algorithm carries a // Source: doc-comment naming its primary paper or treatise — VSOP87A, ELP/MPP02, IAU standards, BPHS, Jaimini. Two subsystems have been re-derived from primary sources behind a documented firewall, and each ships its own audit directory: the lunar theory (2026-05-09) and the sidereal surface (2026-08-17). Each records the primaries, the process, what was searched and rejected, and a generator that re-derives the values so the claim can be re-run rather than taken on trust. See also DATA_PROVENANCE.md. This is the evidence a BUSL-1.1 licensee can audit.

In production

Product	What it is
kundalimcp.com	Agentic-AI Jyotish MCP with the full computation suite. Builds directly on the `vedaksha-*` crates.
kundali.live	Consumer endpoint — chat-based readings and self-serve PDF reports.

FAQ

What is Vedaksha?

A Rust engine for astronomical ephemeris and Vedic astrology (Jyotish), with Python and WebAssembly bindings and an MCP server of 17 tools for AI agents. It computes planetary positions, natal charts, panchanga, dashas, vargas and shadbala.

Can it compute a kundli (kundali, janam kundali)?

Yes. Pass a sidereal ayanamsha, for example IndianOfficial (Lahiri), with a house system such as WholeSign. The MCP tools and the Python binding default to tropical, so a kundli needs the ayanamsha stated; the WASM compute_natal_chart defaults to IndianOfficial.

Is it free to use? Is it AGPL?

It is not AGPL, and it contains no AGPL code. It is source-available under BUSL-1.1: non-commercial use is free; commercial use (a product or service earning revenue from external customers) needs a one-time licence of USD $500 per organisation, covering that version and every later one. Each release converts to Apache-2.0 four years after it ships. BUSL is not an OSI open-source licence.

Does it need ephemeris data files?

No. AnalyticalProvider evaluates VSOP87A and ELP/MPP02 compiled into the binary, which is what the WASM package and the MCP server use. SpkReader reads a JPL DE440s kernel (~31 MB, fetched by scripts/download_de440s.sh) for the highest accuracy.

How accurate is it?

Against JPL Horizons over 1900 to 2025, in apparent geocentric longitude: 0.096″ mean and 0.272″ at worst on the SPK path, 0.160″ mean and 1.473″ at worst on the analytical path. House cusps are not validated against an external reference; see Accuracy.

Which ayanamshas and dasha systems are supported?

Eleven ayanamshas, each derived from a primary source, and eight dasha systems: Vimshottari, Ashtottari, Yogini, Chara, Narayana, Sthira, Niryana Shoola and Maheshwara.

Can an AI agent use it?

Yes. The MCP server runs over stdio or HTTP and is listed in the official MCP Registry as io.github.arthiqlabs/vedaksha-vedic-astrology. See Quick start for a client config.

License

Business Source License 1.1 — SPDX BUSL-1.1, which is what crates.io, PyPI and npm display.

Non-commercial — free (personal, research, education, internal tools).
Commercial — $500, charged once per organization. Unlimited products and seats, perpetual, and it covers the version you license and every version released after it — not charged again per release. Purchase →
Converts to Apache 2.0 four years after each version's release. That future licence text is kept at CHANGE-LICENSE.txt — it is the Change License in BUSL terms, not a licence you may choose today.

See LICENSE, SECURITY.md, CONTRIBUTING.md and MAINTENANCE.md.

Available Tools

17 tools

compute_ashtakavargaA

Read-only

Compute Bhinna Ashtakavarga (raw bindu tables) and Sarvashtakavarga for all 7 planets from sign positions. Source: BPHS Ch.66 vv.13-68. Trikona/Ekadhipatya Shodhana and Pinda Sadhana are not included.

Name	Required	Description
`sun`	Yes	Sign index of Sun (0=Aries…11=Pisces)
`mars`	Yes	Sign index of Mars (0=Aries…11=Pisces)
`moon`	Yes	Sign index of Moon (0=Aries…11=Pisces)
`lagna`	Yes	Sign index of Lagna (Ascendant)
`venus`	Yes	Sign index of Venus (0=Aries…11=Pisces)
`saturn`	Yes	Sign index of Saturn (0=Aries…11=Pisces)
`jupiter`	Yes	Sign index of Jupiter (0=Aries…11=Pisces)
`mercury`	Yes	Sign index of Mercury (0=Aries…11=Pisces)

Output Schema

Name	Required	Description
`tables`	Yes	One Bhinna Ashtakavarga per graha.
`sarvashtakavarga`	Yes	Twelve entries, Aries first.

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the source (BPHS Ch.66 vv.13-68) and explicitly stating that Trikona/Ekadhipatya Shodhana and Pinda Sadhana are not included, which sets accurate expectations for the output. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler: the main function is stated first, the source is given second, and the important exclusions are last. Every sentence contributes meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is read-only, has an output schema, and all 8 required input parameters are fully documented. The description covers the core computation, scope, and limitations. The only minor ambiguity is the relationship between 'all 7 planets' and the required lagna parameter, which is not fully explained, but this is a small gap given the otherwise strong structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and every parameter already has a clear meaning: sign index with 0=Aries through 11=Pisces. The description reinforces the 'sign positions' basis but adds no new parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Compute'), a specific resource ('Bhinna Ashtakavarga' raw bindu tables and 'Sarvashtakavarga'), and the input basis ('from sign positions'). It is clearly distinguishable from the sibling compute_* tools by naming a unique astrological domain and clarifying what is not included.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance about when to use this tool versus alternatives like compute_shadbala, compute_dasha, or compute_gochara. The exclusions tell the agent what the computation does not include, but they do not help an agent decide when this tool is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_bhavasA

Read-only

Compute the whole-sign bhava (house) chart from an ascendant. In the Vedic whole-sign system the entire sign containing the ascendant is the 1st bhava, the next sign the 2nd, and so on — houses do not have cusps within signs. Returns the sign of each of the twelve bhavas with its kendra / trikona / dusthana / upachaya classification, and optionally places supplied grahas into their bhavas.

Name	Required	Description	Default
`planets`	No	Optional map of graha name to sidereal longitude, e.g. {"Mars": 200.4}. Each is placed into its bhava.
`ascendant`	Yes	Sidereal longitude of the ascendant [0, 360)

Output Schema

Name	Required	Description
`houses`	Yes	Twelve entries in order.
`planets`	No	Empty unless grahas were supplied.
`lagna_sign`	Yes	Rashi of the ascendant, 0=Aries … 11=Pisces.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only readOnlyHint available, the description carries the burden of explaining the computation's behavioral traits. It does this well by describing the whole-sign rule, the classification output, and optional graha placement. There is no contradiction with the read-only annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences deliver the core purpose, the computational rule, the return contents, and the optional planet behavior. There is no filler, and the main verb is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the small parameter count, the presence of an output schema, and the read-only annotation, the description is fully sufficient for correct invocation. It covers inputs, computation rule, returned data, and optional behavior without leaving important gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both parameters are already well documented in the schema. The tool description adds little beyond restating sidereal longitude and the optional planet map, so it meets the baseline but does not substantially exceed what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Compute the whole-sign bhava (house) chart from an ascendant.' It also differentiates the tool from cusp-based systems by stating that 'houses do not have cusps within signs,' making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: whenever a whole-sign bhava chart is needed from an ascendant. However, it does not explicitly name sibling alternatives like compute_natal_chart or compute_vargas, nor does it state when this tool should not be used. The context is clear but the exclusion guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_combustionA

Read-only

Compute combustion state for each planet relative to the Sun: principle per BPHS Ch.7 vv.28-29, orbs per Surya Siddhanta IX.6-8 and X.1 (Moon 12, Mars 17, Mercury 14 or 12 retrograde, Jupiter 11, Venus 10 or 8 retrograde, Saturn 15 deg). Returns Combust, DeeplyCombust, or None for Moon, Mars, Mercury, Jupiter, Venus, Saturn with degrees of separation. This is a low-level tool over already-known positions, not a natal-chart tool: call compute_natal_chart first and pass its planets[].longitude (matched by planets[].name) and planets[].retrograde values straight through as this tool's inputs — do not recompute or re-derive them.

Name	Required	Description
`sun`	Yes	Sidereal longitude of Sun [0, 360). From compute_natal_chart's planets[] entry where name == "Sun", field longitude.
`mars`	Yes	Sidereal longitude of Mars [0, 360). From compute_natal_chart's planets[] entry where name == "Mars", field longitude.
`moon`	Yes	Sidereal longitude of Moon [0, 360). From compute_natal_chart's planets[] entry where name == "Moon", field longitude.
`venus`	Yes	Sidereal longitude of Venus [0, 360). From compute_natal_chart's planets[] entry where name == "Venus", field longitude.
`saturn`	Yes	Sidereal longitude of Saturn [0, 360). From compute_natal_chart's planets[] entry where name == "Saturn", field longitude.
`jupiter`	Yes	Sidereal longitude of Jupiter [0, 360). From compute_natal_chart's planets[] entry where name == "Jupiter", field longitude.
`mercury`	Yes	Sidereal longitude of Mercury [0, 360). From compute_natal_chart's planets[] entry where name == "Mercury", field longitude.
`mars_retrograde`	No	True if Mars is retrograde. Accepted for symmetry; Mars's orb is 17 deg either way (Surya Siddhanta IX.6 gives it no retrograde figure), so this does not change the result. From compute_natal_chart's Mars entry, field retrograde.
`venus_retrograde`	No	True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg (Surya Siddhanta IX.7). From compute_natal_chart's Venus entry, field retrograde.
`saturn_retrograde`	No	True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 15 deg either way, so this does not change the result. From compute_natal_chart's Saturn entry, field retrograde.
`jupiter_retrograde`	No	True if Jupiter is retrograde. Accepted for symmetry; Jupiter's orb is 11 deg either way, so this does not change the result. From compute_natal_chart's Jupiter entry, field retrograde.
`mercury_retrograde`	No	True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (Surya Siddhanta IX.8). From compute_natal_chart's Mercury entry, field retrograde.

Output Schema

Name	Required	Description
`states`	Yes	One entry per graha other than the Sun.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already set readOnlyHint=true, and the description adds substantial behavioral context: the tool consumes already-computed positions, uses specific orbs from named sources, returns statuses per planet, and notes which retrograde flags are accepted for symmetry but do not change the result. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause earns its place: it states the computation, cites sources, lists orbs, names outputs, and gives critical usage constraints. It is front-loaded with the core purpose and ends with the most important operational caveat about not recomputing inputs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter tool with a full output schema and read-only annotation, the description is complete: it specifies the required upstream computation, the input semantics, the orbital rules, the result categories, and the exact way to feed data in. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 valuable mapping guidance on top: all longitude and retrograde inputs should be copied directly from compute_natal_chart's planets[] array matched by name, and it clarifies that some retrograde parameters are accepted but inert. This supplements the schema rather than merely repeating it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb and resource: 'Compute combustion state for each planet relative to the Sun.' It names the exact outputs (Combust, DeeplyCombust, or None) and planets involved, and explicitly distinguishes itself from a natal-chart tool, which separates it from sibling tools like compute_natal_chart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance: this is a low-level tool over already-known positions, not a natal-chart tool. It instructs the agent to call compute_natal_chart first and pass planets[].longitude and retrograde values straight through, and tells it not to recompute or re-derive them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_compositeA

Read-only

Compute the midpoint composite chart of two charts: for each graha, the shorter-arc midpoint of its longitude in the two charts, and the arithmetic mean of its two speeds. The two charts must carry the SAME graha names — each graha is paired with its namesake, not with whatever happens to sit at the same position in a list — and a name present in one chart but not the other is an error naming that graha. Longitudes only: this tool needs no birth time, place or ephemeris.

Name	Required	Description	Default
`chart_a`	Yes	Map of graha name to position for the first chart, e.g. {"Sun": {"longitude": 350.0, "speed": 1.0}}. `speed` is optional and defaults to 0.
`chart_b`	Yes	Map of graha name to position for the second chart. Must have exactly the same graha names as chart_a.

Output Schema

Name	Required	Description
`planets`	Yes	One entry per graha present in both charts.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: grahas are paired by namesake rather than list position, a name present in one chart but not the other produces an error naming that graha, and the tool ignores everything except longitudes and speeds. This gives an agent accurate expectations about failure modes and matching semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loads the core computation, and each sentence adds essential information: what is computed, matching/error semantics, and data requirements. There is no filler or repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, input schema, and annotations, the description covers the remaining essentials: prerequisite chart-name identity, error behavior, and what inputs are ignored. An agent can correctly select and invoke the tool with the information provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents chart_a, chart_b, longitude, and speed with 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that chart_a and chart_b must contain exactly the same graha names and that matching is by name, not position. This raises it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific operation, 'compute the midpoint composite chart of two charts,' and defines exactly what is computed: shorter-arc longitude midpoints and arithmetic mean speeds. This clearly distinguishes it from sibling computational tools like compute_synastry or compute_transit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when the tool applies: it works on two charts with matching graha names and needs only longitudes, not birth time/place/ephemeris. It does not explicitly name alternative tools or state when not to use it, so it stops just 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.

compute_dashaA

Read-only

Compute Vedic dasha (planetary period) sequences. Supports eight classical systems: Vimshottari, Ashtottari, Yogini (Moon-longitude based, require moon_longitude); Chara, Narayana (sign based, require BOTH lagna_sign AND graha_signs, since each sign's period length is counted to the sign its lord occupies in this chart); Sthira, NiryanaShoola (niryana_shoola is accepted too) and Maheshwara (Jaimini rashi dashas, require lagna_sign AND graha_longitudes, since the atmakaraka and the tie-breaks of the strength tests read degrees). graha_signs takes the eight sign_index values compute_natal_chart already returns, graha_longitudes the eight sidereal longitudes; Ketu is derived from Rahu and must not be supplied. Yogini takes rounds (1 to 10 whole 36-year rounds) or until (a horizon Julian Day); Chara takes antardashas (twelve per period, BPHS 51.5-51.9). Sthira, NiryanaShoola and Maheshwara use the defaults of the vedic crate's dasha functions (see their module docs) and always carry their antardashas. Sthira and Maheshwara start from the Brahma graha; a chart whose marks leave none returns no_brahma: true with a message, not an error. Returns a JSON dasha tree with start/end Julian Days.

Name	Required	Description	Default
`until`	No	Yogini only: a horizon as a Julian Day (UT1). Whole rounds are produced until the tree reaches it, at least one and at most the maximum of `rounds`; compare the last maha's end_jd with it to see whether it was cut. Exclusive with `rounds`.
`levels`	No	Number of nested dasha levels (1–5). Ignored by the sign-based systems (Chara, Narayana, Sthira, NiryanaShoola, Maheshwara).
`rounds`	No	Yogini only: how many whole 36-year rounds of the cycle to produce. Round 1 is the round from birth, whose first maha is the birth yogini's unelapsed share; each later round runs all eight yoginis whole. Every maha and sub-period carries its `round`. Defaults to 1. Exclusive with `until`. One response carries at most 50,000 periods: ten rounds at four levels, one at five.
`system`	No	Dasha system selector	Vimshottari
`birth_jd`	Yes	Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. This epoch is only added to, never converted: every returned start_jd/end_jd is on the same UT1 scale as the input.
`lagna_sign`	No	Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana, Sthira, NiryanaShoola, Maheshwara. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here.
`antardashas`	No	Chara only: when true each of the twelve periods carries its twelve antardashas in `antar` (BPHS 51.5-51.9: the stronger of the dasha rashi and its seventh starts, by modality, a twelfth of the period each). Defaults to false. Sthira, NiryanaShoola and Maheshwara always carry theirs.
`graha_signs`	No	Natal sign positions of the seven classical grahas plus Rahu, 0-11 each (0 = Aries), as served by compute_natal_chart's sign_index. Required for Chara, Narayana, whose period lengths are chart-dependent — each sign's duration is the count from that sign to the sign its lord actually occupies. Sign indices are used rather than longitudes: they chain directly from compute_natal_chart's sign_index with no conversion, carry no tropical-vs-sidereal ambiguity, and avoid the boundary question of a planet at exactly 30.0 degrees. Ketu is not a field: it is derived as (rahu + 6) mod 12, since the two lunar nodes are always exactly opposite.
`karaka_scheme`	No	Which chara karakas name the atmakaraka for Sthira and Maheshwara: "7" (Sun to Saturn) or "8" (adds Rahu), as compute_karakas takes it. Applies to those two systems only.	7
`moon_longitude`	No	Natal Moon sidereal longitude in degrees [0, 360). Required for Vimshottari, Ashtottari, Yogini.
`graha_longitudes`	No	Sidereal longitudes in degrees [0, 360) of the seven classical grahas plus Rahu, as compute_natal_chart serves them (Rahu from its MeanNode). Required, with lagna_sign, for Sthira, NiryanaShoola and Maheshwara, whose Brahma graha, atmakaraka and strength tie-breaks read degrees within the sign. Ketu is not a field: it is derived 180 degrees from Rahu. Do not also pass graha_signs for these systems.

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to argue safety, and instead it adds genuinely new behavioral facts: the return is a JSON dasha tree keyed by start/end Julian Days, a chart with no Brahma graha returns `no_brahma: true` with a message rather than raising an error, and Yogini results may be truncated by the `until` horizon (verify by comparing the last maha's end_jd). The 50,000-period response cap is also surfaced, though that lives in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, but the body is a single dense paragraph that packs parameter routing, crate-default caveats, and return-format notes into one unbroken block, making it harder to scan than a short bulleted mode table would be. Every sentence carries information, but several clauses duplicate the schema and could be dropped without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with eleven parameters, eight mutually exclusive modes, nested objects, and an output schema, the description covers the mode selection matrix, the epoch time-scale caveat (UT1, never converted), the Ketu derivation rule, the no-brahma edge case, and points to the crate's module docs for the systems it does not detail. The only gap is that it defers Sthira/NiryanaShoola/Maheshwara semantics to external documentation an agent cannot read at call time.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns a step above by consolidating the mode-to-parameter matrix that would otherwise require synthesizing eleven separate schema entries: Moon-longitude systems vs. sign-based systems vs. Jaimini systems, plus the Ketu-is-derived rule and the explicit warning not to pass graha_signs alongside graha_longitudes. It still restates a fair amount of what the schema already says verbatim (index conventions, rounds/until exclusivity), so it is not a full step above.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Compute Vedic dasha (planetary period) sequences') and immediately enumerates the eight supported systems, so the scope is unambiguous. There is no sibling tool that also computes dashas, so no differentiation is required, but the description also never explicitly positions itself against compute_natal_chart or other chart-producing siblings beyond naming them as data sources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states which input data each system consumes, which implicitly tells the agent when a call is valid, and it repeatedly points at compute_natal_chart as the source of graha_signs/graha_longitudes. However, it never states when an agent should choose this tool versus, say, compute_karakas or compute_vargas, nor does it give any 'use this when the user asks for a timeline/period sequence' guidance; usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_drishtiA

Read-only

Compute graha drishti — Vedic sign aspects — for all nine grahas. Unlike Western aspects, drishti is cast from sign to sign and is asymmetric: every graha aspects the 7th from itself, and Mars additionally aspects the 4th and 8th, Jupiter the 5th and 9th, Saturn the 3rd and 10th. Returns each aspect with its graded strength (Full, ThreeQuarter, Half, Quarter) and the house distance.

Name	Required	Description
`sun`	Yes	Sidereal longitude of Sun [0, 360)
`ketu`	Yes	Sidereal longitude of Ketu [0, 360)
`mars`	Yes	Sidereal longitude of Mars [0, 360)
`moon`	Yes	Sidereal longitude of Moon [0, 360)
`rahu`	Yes	Sidereal longitude of Rahu [0, 360)
`venus`	Yes	Sidereal longitude of Venus [0, 360)
`saturn`	Yes	Sidereal longitude of Saturn [0, 360)
`jupiter`	Yes	Sidereal longitude of Jupiter [0, 360)
`mercury`	Yes	Sidereal longitude of Mercury [0, 360)

Output Schema

Name	Required	Description
`aspects`	Yes

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already signal readOnlyHint=true; the description adds substantial behavioral detail beyond that: every graha aspects the 7th, Mars/Jupiter/Saturn have extra aspects, and the output includes graded strength and house distance. This gives a clear model of what happens when the tool is invoked.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the operation and scope first, then presents the key asymmetric rules and output shape. Every sentence contributes useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the read-only annotation, complete parameter schema, and output schema, the description supplies the remaining essential context: the Vedic drishti model, special aspect rules, and returned strength/distance values. An agent has enough information to select and call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter is documented with the same format and range, so the description does not need to add much. The phrase 'for all nine grahas' maps to the required parameters but adds no semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: 'Compute graha drishti — Vedic sign aspects — for all nine grahas,' giving a specific verb, resource, and full scope. It differentiates from Western aspects and lists the unusual aspect rules, but it does not explicitly name or distinguish a sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear usage context by explaining that drishti is sign-to-sign, asymmetric, and has special extra aspects for Mars, Jupiter, and Saturn, while contrasting with Western aspects. However, it never names an alternative tool or states a when-not-to-use condition, so it lacks explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_gocharaA

Read-only

Compute Gochara (transit interpretation) for the seven grahas against a natal reference sign per BPHS Ch.29. Returns favourable/unfavourable verdict, house from natal, and raw vedha (obstruction) candidates per planet. The natal reference sign is the caller's choice — typically the natal Moon's sign (Chandra Gochara) or the natal Lagna's sign. Rahu and Ketu are not included.

Name	Required	Description	Default
`sun`	Yes	Transit sign index of Sun (0=Aries … 11=Pisces)
`mars`	Yes	Transit sign index of Mars
`moon`	Yes	Transit sign index of Moon
`venus`	Yes	Transit sign index of Venus
`saturn`	Yes	Transit sign index of Saturn
`school`	No	Exemption profile applied to the raw vedha candidate list	Geometry
`jupiter`	Yes	Transit sign index of Jupiter
`mercury`	Yes	Transit sign index of Mercury
`vedha_table`	No	Vedha pair table source	Bphs29
`natal_reference_sign`	Yes	Sign index of the natal reference point — natal Moon for Chandra Gochara, natal Lagna for Lagna-based Gochara

Output Schema

Name	Required	Description
`entries`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful behavioral context: the BPHS Ch.29 basis, the output items (favourable/unfavourable verdict, house from natal, raw vedha candidates), and the exclusion of Rahu/Ketu. There is no contradiction with 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: purpose, output, and usage context are each stated once and front-loaded. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for an agent to select and invoke the tool correctly given the rich schema and output schema. It supplies the missing domain context (BPHS Ch.29, seven grahas, natal reference choice, node exclusion) while the schema covers parameter mechanics and the output schema covers return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters including the two enums. The description's natal-reference guidance (Moon vs Lagna) largely duplicates the natal_reference_sign schema description. It adds minimal extra parameter meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Compute Gochara (transit interpretation) for the seven grahas against a natal reference sign per BPHS Ch.29.' It also differentiates this tool from siblings like compute_transit by naming Gochara, the seven-planet scope, and the natal reference sign. The explicit exclusion of Rahu and Ketu further sharpens the tool's identity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operational context: the caller chooses the natal reference sign, typically Moon (Chandra Gochara) or Lagna. It also states a when-not condition by saying Rahu and Ketu are not included. However, it never names a sibling alternative such as compute_transit or search_transits, so it stops short of fully explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_karakasA

Read-only

Compute Jaimini Chara Karaka assignments from sidereal planet longitudes. Ranks planets by degrees within their current sign: highest = Atmakaraka (soul significator), lowest = Darakaraka (spouse significator). Supports 7-karaka (Sun–Saturn) and 8-karaka (adds Rahu) schemes.

Name	Required	Description	Default
`sun`	Yes	Sidereal longitude of Sun [0, 360)
`mars`	Yes	Sidereal longitude of Mars [0, 360)
`moon`	Yes	Sidereal longitude of Moon [0, 360)
`rahu`	No	Sidereal longitude of Rahu [0, 360). Required for scheme '8'.
`venus`	Yes	Sidereal longitude of Venus [0, 360)
`saturn`	Yes	Sidereal longitude of Saturn [0, 360)
`scheme`	No	Karaka scheme: '7' (default, Sun–Saturn) or '8' (adds Rahu + Pitrikaraka)	7
`jupiter`	Yes	Sidereal longitude of Jupiter [0, 360)
`mercury`	Yes	Sidereal longitude of Mercury [0, 360)

Output Schema

Name	Required	Description
`karakas`	Yes	One entry per graha, ordered by rank.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already signals a safe read operation, and the description adds substantive behavioral detail: planets are ranked by degrees within their sign, highest is Atmakaraka, lowest is Darakaraka, and the 7- vs 8-karaka schemes differ by the inclusion of Rahu. This goes beyond the annotation without contradicting it, though tie-breaking or edge-case behavior is not covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences front-load the purpose, follow with the ranking rule, and end with scheme options. There is no filler and no repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a pure computation tool with readOnlyHint, a fully described schema, and an output schema, the description supplies the core algorithm and scheme semantics needed for correct invocation. It omits minor nuances like the Pitrikaraka label in scheme 8 or tie-breaking rules, but these are either captured in the schema or not essential to selecting and calling the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all nine parameters with descriptions, so the baseline is 3. The description earns extra credit by explaining that longitudes are 'sidereal', that ranking uses degrees within the current sign, and that Rahu is the additional body for scheme 8 – giving meaning to the parameter values rather than merely naming them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the specific verb 'Compute' and the resource 'Jaimini Chara Karaka assignments', then anchors the computation to sidereal longitudes and rank-by-degree logic. This clearly differentiates the tool from sibling compute_* tools such as compute_natal_chart or compute_dasha, even though it never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the exact scope of the tool: computing Chara Karaka assignments and supporting two schemes, which implicitly tells an agent this is the karaka-specific tool among many compute siblings. However, it does not explicitly mention when not to use it or name alternative tools, so routing guidance is slightly incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_natal_chartA

Read-only

Compute a natal astrological chart for a given time and location. Returns JSON with each body's longitude, latitude, speed, sign, house, dignity and retrograde flag, the house cusps with ascendant and MC, the aspects, and the ayanamsha applied. Pass a sidereal ayanamsha for a Vedic chart (kundali); the default is tropical. To get a property graph, pass this output to emit_graph.

Name	Required	Description	Default
`latitude`	Yes	Geographic latitude in degrees [-90, +90]
`ayanamsha`	No	Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession \| FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP \| Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr \| Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 \| SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 \| Yukteshwar = Yukteswar, The Holy Science (1894) \| RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos \| PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa \| TrueChitra [star] = Self-describing condition; Spica per Hipparcos \| ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 \| GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49.	Tropical
`longitude`	Yes	Geographic longitude in degrees [-180, +180], east positive
`julian_day`	Yes	Julian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms (planetary positions, nutation, obliquity) and evaluates the Earth-rotation term — sidereal time, and hence the ascendant, the MC and all twelve house cusps — at this UT1 value directly. Supplying a TDB Julian Day rotates every cusp by 0.289° (17.3') at today's ΔT ≈ 69 s.
`house_system`	No	House system: Placidus, Koch, Equal, WholeSign, etc.	Placidus

Output Schema

Name	Required	Description
`houses`	Yes
`aspects`	Yes
`planets`	Yes	One entry per computed body.
`julian_day`	Yes	The Julian Day the chart was cast for, echoed back.
`config_summary`	No	One-line record of the ephemeris, house system and ayanamsha used.
`true_ayanamsha_value`	No	True ayanamsha (mean plus nutation in longitude) applied, in degrees. Zero for a tropical chart.

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the composition pathway into emit_graph and clarifies the tropical/sidereal branch, both useful behavior not present in structured fields. The critical precision caveat (UT1 vs TT) lives in the schema rather than the description, so this is not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then outputs, then selection guidance. The output-enumeration sentence duplicates the output schema somewhat but reads as a useful summary rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 enumerate return fields, and it covers the core call correctly. For a tool sitting among sixteen chart-related siblings, though, it omits any statement about what it does NOT cover (divisional charts, bhava analysis, aspects) that would help an agent choose correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the ayanamsha enum is documented exhaustively, so the schema carries the burden. The description's ayanamsha note ('sidereal for a Vedic chart, default tropical') adds a small amount of interpretive framing but is largely restated in the enum's own 'Pass Tropical for no rotation' text; julian_day, latitude, longitude and house_system get nothing beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (compute a natal chart) plus the required inputs (time and location), and frames the two output modes — tropical default vs sidereal for a Vedic kundali. It does not, however, distinguish itself from the many adjacent chart tools (compute_bhavas, compute_vargas, compute_drishti) that also operate on a natal chart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers one clear routing rule — 'pass this output to emit_graph' for a property graph — and explains when to choose a sidereal ayanamsha versus the tropical default. There is no guidance on when to use this versus sibling computation tools, which is a real gap given sixteen siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_panchangaA

Read-only

Compute the panchanga — the five limbs of the Vedic almanac — for an instant: tithi (lunar day, with paksha and lord), vara (weekday reckoned from local sunrise, with its lord and the Rahu and Gulika Kalam windows as Julian Days), nakshatra (with pada), yoga (one of the 27 nithya yogas, with degrees remaining), and karana (half-tithi). Takes sidereal longitudes; all returned instants are Julian Days (UT). vara.from_sunrise reports HOW the weekday was reckoned: true means it was taken from an actual local sunrise (the Vedic definition); false means no sunrise exists to reckon from — the polar day or polar night, above about ±66.5° latitude — and the value is the observer's local CIVIL weekday as a documented fallback, which is a different quantity. Check it before presenting the vara at high latitude. vara.rahu_kalam being null is NOT the same signal: the Kalam windows can also be null while from_sunrise is true.

Name	Required	Description
`jd`	Yes	Julian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which the vara is reckoned from; every returned instant, the Rahu and Gulika Kalam bounds included, is on this same UT1 scale. Supplying a TT/TDB Julian Day shifts sunrise by ΔT (≈ 69 s today), enough to move the vara for an instant near sunrise.
`sun`	Yes	Sidereal longitude of Sun [0, 360)
`moon`	Yes	Sidereal longitude of Moon [0, 360)
`latitude`	Yes	Observer latitude in degrees. Required — the vara is reckoned from local sunrise, so it depends on the observer.
`longitude`	Yes	Observer longitude in degrees, east positive. Required.
`elevation_m`	No	Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise — at 3650 m (Lhasa) 9.2 minutes earlier, enough to change the vara in that window. Pass the same value as search_muhurta for the same observer, or the two tools can report different weekdays for one instant.
`tz_offset_minutes`	No	Offset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Used only to name the vara's weekday.

Output Schema

Name	Required	Description
`vara`	Yes
`yoga`	Yes
`tithi`	Yes
`karana`	Yes
`nakshatra`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description reveals non-obvious behavioral details: the vara reckoning mechanic, the civil-weekday fallback when no sunrise exists, and the important distinction between a null rahu_kalam and from_sunrise being false. It also specifies the UT1 time scale and the ΔT sensitivity near sunrise, which are critical and undocumented elsewhere. This is exactly the kind of context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and becomes more detailed only where needed for edge cases. Every sentence carries information, and the length is justified by the genuine complexity of the vara and rahu_kalam behavior. It could be tightened slightly, but it remains highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers time-scale conventions, the polar fallback, the null-window distinction, and even warns to pass the same elevation_m as search_muhurta for consistency. With an output schema present, nothing an agent needs to invoke this tool correctly is missing. It is fully complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of the 7 parameters with already-thorough descriptions, including jd time-scale warnings and elevation's effect on sunrise. The main description reinforces that inputs are sidereal longitudes and outputs are in Julian Days (UT), but adds little parameter-level meaning beyond the schema. A baseline 3 is appropriate since the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb 'Compute' and a precise resource, 'the panchanga — the five limbs of the Vedic almanac — for an instant', then enumerates all five limbs (tithi, vara, nakshatra, yoga, karana). This distinguishes it clearly from sibling computation tools like compute_natal_chart or compute_dasha. No ambiguity remains about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear operational context: it works on a single instant from sidereal longitudes, returns Julian Days (UT), and explains the polar-day/night fallback for vara at high latitude. It also warns to check vara.from_sunrise before presenting the weekday at high latitude. It does not explicitly name alternative tools, but the context is sufficient for correct use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_shadbalaA

Read-only

Compute the complete six-fold Shadbala of the seven grahas (Sun to Saturn) for a birth moment and place, per BPHS Ch.27, with Ishta and Kashta Phala per Ch.28, in virupas. Pass the moment and the place; the tool casts the chart itself and reads sunrise, sunset and the next sunrise from the engine. Every part is in the output, each in its own field: Sthana (uccha, saptavargaja, ojhayugma, kendradi, drekkana), Dig (continuous, the arc from the weak cusp over 3, 27.7), Kala (nathonnata, paksha, tribhaga, abda, masa, vara, hora, ayana and yuddha, which is signed), Cheshta (the cheshta kendra for Mars to Saturn, the Sun's ayana and the Moon's paksha bala, 27.18 and 27.24-25), Naisargika and Drik (a quarter of the benefic sphuta drishti added, a quarter of the malefic taken away, the aspect of Mercury and Jupiter added whole, 27.19; it can be negative or pass 60). The Sun's ayana and the Moon's paksha bala are counted once in kala and once in cheshta, each undoubled. The rules are the verses' defaults; the benefic and malefic grahas are those of BPHS 3.11, with Rahu (the mean node) and Ketu counting only as malefic company for Mercury. Each graha also carries its motion state (vakra, anuvakra, ... atichara, 27.21-23) against the mean geocentric motion; it is reported beside the strengths and is not part of any total. The Sun must both rise and set at the place: in the polar day or night there is no Hindu day to divide into thirds and horas, and the call fails by name.

Name	Required	Description	Default
`latitude`	Yes	Geographic latitude in degrees, north positive. The Hindu day is reckoned from this place's sunrise.
`ayanamsha`	Yes	Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Tropical is refused: this tool is defined on sidereal positions. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession \| FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP \| Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr \| Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 \| SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 \| Yukteshwar = Yukteswar, The Holy Science (1894) \| RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos \| PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa \| TrueChitra [star] = Self-describing condition; Spica per Hipparcos \| ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 \| GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49.
`longitude`	Yes	Geographic longitude in degrees, east positive.
`julian_day`	Yes	Julian Day number in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day.
`elevation_m`	No	Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise and sunset.
`house_system`	No	House system whose first, fourth, seventh and tenth cusps Dig Bala is measured from, and whose house placements give Kendradi Bala: Placidus, Koch, Equal, WholeSign, etc. The same names compute_natal_chart takes.	Placidus
`tz_offset_minutes`	No	Offset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Names the calendar date of the sunrise that begins the Hindu day, from which the lords of the year, month and day (abda, masa, vara) are reckoned.

Output Schema

Name	Required	Description
`cusps`	Yes	The four angular cusps Dig Bala is measured from, sidereal degrees.
`moment`	Yes	The birth moment Kala Bala was reckoned from. Every instant is a Julian Day (UT1).
`planets`	Yes	The seven grahas, Sun to Saturn, in the order Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn. All strengths are in virupas.
`julian_day`	Yes	The Julian Day (UT1) the strengths were computed for, echoed back.
`house_system`	Yes	The house system requested. When `polar_fallback` is true it was undefined at this latitude, and the cusps and house placements come from the fallback the natal chart uses.
`polar_fallback`	Yes	True when the requested house system was undefined at this latitude and a fallback was used, so Dig Bala and Kendradi Bala are read from the fallback's cusps and houses.
`true_ayanamsha_value`	Yes	True ayanamsha (mean plus nutation in longitude) applied, in degrees.

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the readOnly/openWorld annotations: the polar day/night failure, that Drik Bala can be negative or exceed 60, that ayana and paksha bala are counted once in two places and undoubled, that motion state is reported but excluded from totals, and that tropical is refused. These are exactly the surprises an agent must know before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly, but the middle is a dense enumeration of every sub-component and verse citation (uccha, saptavargaja, ojhayugma, 27.18, 27.24-25, 3.11, 27.21-23) that largely restates what an output schema already exists to convey. The behavioral notes at the end earn their place; the taxonomy dump is bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a computation of this complexity with an output schema present, the description covers what is computed, how sub-balas are combined (e.g. a quarter of benefic sphuta drishti added, a quarter of malefic subtracted), the non-doubling rule, what is excluded from totals, and the failure mode. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter is already documented in depth (ayanamsha systems, elevation horizon dip, tz_offset naming the sunrise date), so the schema does the heavy lifting. The description adds only indirect parameter context ('pass the moment and the place', the sunrise requirement tied to latitude) rather than new per-parameter meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Compute the complete six-fold Shadbala of the seven grahas ... for a birth moment and place') plus the governing source (BPHS Ch.27/28) and unit (virupas). The scope is unmistakably distinct from siblings like compute_vargas, compute_karakas, or compute_natal_chart without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tells the agent what to supply ('Pass the moment and the place; the tool casts the chart itself') and pre-empts a dependency the agent would otherwise assume, i.e. that a chart must be computed first. It also states an explicit when-not condition: if the Sun neither rises nor sets, the call fails by name. No explicit routing against sibling tools, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_synastryA

Read-only

Compute synastry — the aspects each graha in one chart makes to each graha in another chart. Every graha in chart A is tested against every graha in chart B (the two charts do not need the same graha names), and each hit is returned with its aspect type, orb in degrees and strength (1.0 at exact, falling linearly to 0.0 at the orb boundary). Orbs are the traditional Lilly values — conjunction, trine and opposition 8°, square 7°, sextile 6°, minors 2° — scaled by orb_factor. Longitudes only: this tool needs no birth time, place or ephemeris.

Name	Required	Description	Default
`chart_a`	Yes	Map of graha name to sidereal longitude [0, 360) for the first chart, e.g. {"Sun": 10.0, "Moon": 130.0}.
`chart_b`	Yes	Map of graha name to sidereal longitude [0, 360) for the second chart. Need not use the same names as chart_a.
`aspect_set`	No	'major' (default) tests the five Ptolemaic aspects; 'all' adds semi-sextile, semi-square, quintile, sesquiquadrate, bi-quintile and quincunx.	major
`orb_factor`	No	Multiplier on the default orbs. 1.0 (default) is standard, 0.5 is tight. Must be greater than 0 and at most 5.0, above which the major-aspect windows cover every separation.

Output Schema

Name	Required	Description
`aspects`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses detailed behavior beyond the readOnlyHint annotation: every graha in chart A is tested against every graha in chart B, hits include aspect type/orb/strength, strength falls linearly from 1.0 to 0.0, and orbs follow Lilly values scaled by orb_factor. This gives the agent a precise model of what the tool will do.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences: the first states the core purpose, the second details the algorithm and output, and the third states the input prerequisites. Every sentence carries necessary information without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with four parameters, two of which are nested objects, the description covers the algorithm, the output shape, orb conventions, scaling behavior, and the minimal input requirements. The presence of an output schema further reduces the need to document return values, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% parameter coverage, so the baseline is 3. The description adds meaningful semantic detail beyond the schema by explaining the orb values, orb_factor scaling, and strength formula, which clarifies how orb_factor changes results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: compute synastry aspects between two charts, with the precise cross-testing model. It clearly distinguishes this from siblings like compute_composite or compute_drishti by describing exactly what the tool computes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when this tool is appropriate: comparing two charts by longitude only, with no need for birth time, place, or ephemeris. It does not explicitly name alternatives or exclusion conditions, but the scope is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_transitA

Read-only

Compute transiting planet positions relative to a natal chart at a specific moment. Returns planet longitudes for the transit time alongside natal positions, enabling aspect calculation between transit and natal placements.

Name	Required	Description
`natal_jd`	Yes	Julian Day of the natal chart in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms.
`natal_lat`	Yes	Natal geographic latitude in degrees [-90, +90]
`natal_lon`	Yes	Natal geographic longitude in degrees [-180, +180], east positive
`transit_jd`	Yes	Julian Day of the transit moment to compute, in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms.

Output Schema

Name	Required	Description
`natal_jd`	Yes	Julian Day of the natal chart, echoed back.
`transit_jd`	Yes	Julian Day of the transit moment, echoed back.
`natal_positions`	Yes	Natal positions used for the comparison.
`transit_positions`	Yes	Positions at the transit moment.
`transit_natal_aspects`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (readOnlyHint=true), lowering the burden. The description adds useful framing by disclosing that the result contains both transit and natal longitudes for aspect work. It does not go deeper into edge behaviors (e.g., invalid date handling, planet set included, precision), which is acceptable but not rich given the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: the first commits to the computation, the second to the return shape and purpose. Front-loaded and maximally signal-dense — every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 100% parameter coverage, a rich output schema, and read-only annotations, the description covers what is computed, relative to what, and for what purpose. The only gap is that the roles of natal_lat/natal_lon in a transit computation are left to the schema, which documents their units but not their algorithmic function. Still, an agent can select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — all four parameters (natal_jd, natal_lat, natal_lon, transit_jd) have detailed unit/format guidance, including the UT1-vs-TT distinction. The tool description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('compute') and resource ('transiting planet positions relative to a natal chart at a specific moment'), then specifies the output shape (transit longitudes alongside natal positions). The scope is unambiguous enough to distinguish it from compute_natal_chart (natal only), compute_synastry (two-person comparison), and compute_gochara, without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The use case is implied via 'enabling aspect calculation between transit and natal placements,' which gives clear context. However, it never explicitly routes the agent away from domain-overlapping siblings like compute_gochara (also transit-related) or search_transits (searching transits), so when-to-use vs alternatives 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.

compute_vargasA

Read-only

Compute Vedic divisional charts (vargas). Given a time and place, returns one chart per requested division: the varga lagna, and for each of the ten bodies compute_natal_chart returns — the seven grahas plus the mean, true and osculating lunar node — its rashi longitude, the sign it occupies within that varga, its dignity in that sign, and its whole-sign bhava counted from the varga lagna. Ketu is not listed separately: it is the node's opposite point, 180 degrees away. The nodes carry no dignity, so that field is absent for them. Supply planet_longitude instead to divide a single longitude without an ephemeris lookup, in which case no graha name, dignity or bhava is returned because none is defined. Vargas are classically read on a sidereal zodiac: pass an ayanamsha, or accept the Tropical default this surface uses everywhere. Source: BPHS Ch. 6-7.

Name	Required	Description	Default
`latitude`	Yes	Geographic latitude in degrees [-90, +90]
`ayanamsha`	No	Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession \| FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP \| Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr \| Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 \| SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 \| Yukteshwar = Yukteswar, The Holy Science (1894) \| RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos \| PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa \| TrueChitra [star] = Self-describing condition; Spica per Hipparcos \| ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 \| GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49.
`divisions`	Yes	Varga division codes to compute, e.g. ["D1", "D9", "D10"]
`longitude`	Yes	Geographic longitude in degrees [-180, +180], east positive
`tradition`	No	Which Parashari reading to use where the texts diverge. 'modality' (default) starts the division from a movable/fixed/dual sign; 'element' starts it from a fire/earth/air/water sign. This changes D16, D20, D30 and D45 only; every other varga is identical under both. Source: BPHS Ch. 6; Phala Deepika Ch. 2.	modality
`julian_day`	Yes	Julian Day number in UT1 (Universal Time) — not TT, not TDB. Same scale as compute_natal_chart's julian_day: the engine converts to TT internally for the dynamical terms and uses UT1 directly for the Earth-rotation term.
`planet_longitude`	No	Sidereal longitude of a single body in degrees [0, 360). When supplied, only this longitude is divided and no ephemeris is consulted; the result carries no graha name, dignity or bhava.

Output Schema

Name	Required	Description
`vargas`	Yes	One entry per requested division, in the order requested.
`tradition`	Yes	The tradition actually used: 'modality' or 'element'.
`julian_day`	Yes	The Julian Day the vargas were computed for, echoed back.
`true_ayanamsha_value`	No	True ayanamsha (mean plus nutation in longitude) applied before dividing, in degrees. Zero when Tropical.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses important traits: Ketu is not listed separately because it is the node's opposite point, nodes carry no dignity so that field is absent, and the planet_longitude mode returns no graha name, dignity, or bhava. These are not visible in the annotations and are essential for correct interpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but not bloated, front-loading the purpose and then proceeding through output details, edge cases, and default behavior. Every sentence adds value, and the source citation is a compact closing detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and readOnlyHint is set, the description covers the critical edge cases: Ketu omission, node dignity absence, the planet_longitude mode, and the ayanamsha default. No essential behavioral detail for invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 useful parameter context not in the schema: the Tropical default ayanamsha and the specific body set from compute_natal_chart. It does not add much beyond the schema's already-detailed planet_longitude explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Compute Vedic divisional charts (vargas).' It then details the exact output per division—varga lagna, rashi longitude, sign, dignity, bhava—and references the ten bodies from compute_natal_chart, which distinguishes this tool from its sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context by describing the standard time-and-place mode and the alternate planet_longitude mode for dividing a single longitude without an ephemeris lookup. It also mentions the Tropical default. However, it never explicitly states when to choose this tool over other chart-related siblings like compute_bhavas.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

emit_graphA

Read-only

Turn a chart into a queryable property graph. Accepts the output of compute_natal_chart directly (pass latitude and longitude alongside it), or an existing ChartGraph. Emits Neo4j Cypher, SurrealDB SurrealQL, JSON-LD, plain JSON, or RAG embedding text.

Name	Required	Description
`format`	Yes	Target output format
`latitude`	No	Observer latitude, degrees north. Required when chart_json is a computed chart; a chart result does not record where it was cast. Ignored for an existing ChartGraph.
`longitude`	No	Observer longitude, degrees east. Required when chart_json is a computed chart.
`chart_json`	Yes	Either the output of compute_natal_chart ({planets, houses, aspects, ...}), which is converted to a graph here, or an existing ChartGraph ({nodes, edges, chart_id, classification})
`classification`	No	Optional label or session ID attached to emitted nodes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already signals non-mutating behavior, and the description adds meaningful behavioral context: it converts chart data into a property graph, accepts both raw compute_natal_chart output and pre-built ChartGraph objects, and produces multiple named formats. It also notes latitude/longitude are ignored for existing ChartGraph instances, which is useful beyond 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundant phrasing. The core action is front-loaded, and the input forms and output formats are compactly enumerated without wasting tokens.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the 100% schema coverage, covers the essential invocation details: required inputs, conditional coordinate requirements, accepted input forms, and output format options. The main gap is the lack of an output schema or explicit note about how the emitted text is returned, but the listed formats make the behavior sufficiently predictable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter well. The description adds value by clarifying the relationship between chart_json and latitude/longitude, noting that computed charts require coordinates while existing ChartGraphs do not, and naming compute_natal_chart as the direct source of chart_json. This goes beyond the schema's individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Turn a chart into a queryable property graph.' It lists concrete output formats (Cypher, SurrealQL, JSON-LD, JSON, RAG embedding text) and names compute_natal_chart as the upstream input, making it easy to distinguish from sibling compute_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates when to use the tool: when you have a computed chart or an existing ChartGraph and need a queryable graph format. It also explains the coordinate requirement for computed charts. It does not explicitly say 'use this instead of compute_* for graph output,' but the context is unambiguous enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_muhurtaA

Read-only

Search for auspicious time windows (muhurta) within a given period for a geographic location. Returns ranked muhurta candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions. The search window is capped at 30 days (see MUHURTA_SEARCH_RANGE_TOO_LARGE), a scope limit; for a longer horizon, issue several searches.

Name	Required	Description
`end_jd`	Yes	End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The span from start_jd to end_jd must not exceed 30 days.
`latitude`	Yes	Geographic latitude in degrees [-90, +90]
`start_jd`	Yes	Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which each candidate's vara is reckoned from; every returned jd, tithi_end_jd and nakshatra_end_jd is on this same UT1 scale. The span from start_jd to end_jd must not exceed 30 days.
`longitude`	Yes	Geographic longitude in degrees [-180, +180], east positive
`elevation_m`	No	Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise, which is what each candidate's vara is reckoned from — at 3650 m (Lhasa) 9.2 minutes earlier. Pass the same value as compute_panchanga for the same observer, or the two tools can report different weekdays for one instant.
`min_quality`	No	Minimum quality score [0.0, 1.0] for muhurta inclusion (default 0.5)
`tz_offset_minutes`	No	Offset of the observer's civil clock from UT, in minutes. Names the vara (weekday) reported for each candidate — it does not change which sunrise bounds the vara, only what that vara is called. Default 0 (UT).

Output Schema

Name	Required	Description
`end_jd`	Yes	End of the searched window, echoed back.
`results`	Yes
`latitude`	No	Latitude used, in degrees.
`start_jd`	Yes	Start of the searched window, echoed back.
`longitude`	No	Longitude used, in degrees.
`elevation_m`	No	Elevation used, in metres.
`min_quality`	No	Quality floor the search applied.
`result_count`	Yes	Number of entries in results.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description is free to add operational traits — the ranked-with-scores return shape, the hard 30-day cap, and the named error MUHURTA_SEARCH_RANGE_TOO_LARGE. That error-code disclosure is genuinely useful for an agent to handle failure, though the cost/performance characteristics of a wide search are left implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then return shape, then the constraint and its remedy. The error code and the 'issue several searches' fallback both earn their place; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values in detail, yet it still signals that results are ranked and scored. Combined with the disclosed window cap, its error code, and the multi-search workaround, an agent has everything needed to call this correctly and recover from the range failure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter — including the UT1-vs-TT nuance on start_jd, the tz_offset_minutes vara naming, and the elevation sunrise dip — is already fully documented in structured fields. The description only restates the 30-day span limit on start_jd/end_jd and adds no parameter semantics of its own, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource — search for auspicious muhurta windows for a geographic location — and adds what comes back (ranked candidates scored on tithi, nakshatra, yoga, karana, planetary positions). The resource is distinctive enough that no listed sibling (search_transits, compute_panchanga, etc.) could be confused with it, though no sibling is named to confirm the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear operating context plus an explicit workaround: the window is capped at 30 days, and for a longer horizon you issue several searches. What is missing is routing guidance against the compute_* siblings — e.g. when to search for a window versus when to use compute_panchanga for a specific instant — which the schema hints at but the description never states.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_transitsA

Read-only

Search for transiting planet–natal planet aspects within a time window. Supply natal positions and a Julian Day range; receive a list of exact transit moments with aspect type, orb, and applying/separating status.

Name	Required	Description
`bodies`	No	Transiting bodies to include. Defaults to all planets.
`end_jd`	Yes	End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB.
`aspects`	No	Aspect types to filter (e.g. conjunction, opposition, trine). Defaults to major aspects.
`max_orb`	No	Maximum orb in degrees (default 1.0)
`start_jd`	Yes	Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms; each event's exact_jd is returned on this same UT1 scale.
`natal_positions`	Yes	Array of natal planet positions to check transits against

Output Schema

Name	Required	Description
`end_jd`	Yes	End of the searched window, echoed back.
`events`	Yes
`max_orb`	No	Orb the search used, in degrees.
`start_jd`	Yes	Start of the searched window, echoed back.
`event_count`	Yes	Number of entries in events.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns exact transit moments with aspect type, orb, and applying/separating status, adding behavioral detail beyond the readOnlyHint annotation. It does not mention limitations such as search range size or whether bodies/aspects default to all/major, but those are covered in schema. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundant words; the subject-action-object structure is front-loaded and immediately legible. Every clause contributes either the input requirement or the expected output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 6-parameter schema with 100% coverage, detailed parameter descriptions, and an output schema, the description is sufficient to orient an agent. It omits explicit alternative routing, but the time-window focus and 'search' verb are enough to select this tool among siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 schema already richly documents each parameter (e.g., UT1 vs TT conversion in start_jd). The tool description itself only mentions natal positions and a Julian Day range, which maps to required params but adds no extra meaning not already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Search for') on a well-defined resource ('transiting planet–natal planet aspects') within a bounded time window. This clearly differentiates it from siblings like compute_transit, which would calculate a single transit, and compute_gochara, which returns current positions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies usage context: when an agent has natal positions and needs a list of aspect events over a Julian Day range. However, it does not explicitly state when to prefer this over alternatives like compute_transit for a single moment or search_muhurta for electional timing, so no exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 24, 2026

Changedcompute_dasha11 fields changed

addedInput schema / properties / antardashas

Added value: +{
+  "default": false,
+  "description": "Chara only: when true each of the twelve periods carries its twelve antardashas in `antar` (BPHS 51.5-51.9: the stronger of the dasha rashi and its seventh starts, by modality, a twelfth of the period each). Defaults to false. Sthira, NiryanaShoola and Maheshwara always carry theirs.",
+  "type": "boolean"
+}

addedInput schema / properties / graha_longitudes

Added value: +{
+  "description": "Sidereal longitudes in degrees [0, 360) of the seven classical grahas plus Rahu, as compute_natal_chart serves them (Rahu from its MeanNode). Required, with lagna_sign, for Sthira, NiryanaShoola and Maheshwara, whose Brahma graha, atmakaraka and strength tie-breaks read degrees within the sign. Ketu is not a field: it is derived 180 degrees from Rahu. Do not also pass graha_signs for these systems.",
+  "properties": {
+    "jupiter": {
+      "description": "Jupiter's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "mars": {
+      "description": "Mars's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "mercury": {
+      "description": "Mercury's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "moon": {
+      "description": "Moon's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "rahu": {
+      "description": "Rahu's (north lunar node's) sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "saturn": {
+      "description": "Saturn's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "sun": {
+      "description": "Sun's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    },
+    "venus": {
+      "description": "Venus's sidereal longitude.",
+      "exclusiveMaximum": 360,
+      "minimum": 0,
+      "type": "number"
+    }
+  },
+  "required": [
+    "sun",
+    "moon",
+    "mars",
+    "mercury",
+    "jupiter",
+    "venus",
+    "saturn",
+    "rahu"
+  ],
+  "type": "object"
+}

addedInput schema / properties / karaka_scheme

Added value: +{
+  "default": "7",
+  "description": "Which chara karakas name the atmakaraka for Sthira and Maheshwara: \"7\" (Sun to Saturn) or \"8\" (adds Rahu), as compute_karakas takes it. Applies to those two systems only.",
+  "enum": [
+    "7",
+    "8"
+  ],
+  "type": "string"
+}

changedInput schema / properties / lagna_sign / description

Previous value: -"Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here."New value: +"Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana, Sthira, NiryanaShoola, Maheshwara. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here."

changedInput schema / properties / levels / description

Previous value: -"Number of nested dasha levels (1–5). Ignored by Chara and Narayana."New value: +"Number of nested dasha levels (1–5). Ignored by the sign-based systems (Chara, Narayana, Sthira, NiryanaShoola, Maheshwara)."

addedInput schema / properties / moon_longitude / exclusiveMaximum
```
Added value: +360
```
removedInput schema / properties / moon_longitude / maximum
```
Removed value: -360
```

addedInput schema / properties / rounds

Added value: +{
+  "default": 1,
+  "description": "Yogini only: how many whole 36-year rounds of the cycle to produce. Round 1 is the round from birth, whose first maha is the birth yogini's unelapsed share; each later round runs all eight yoginis whole. Every maha and sub-period carries its `round`. Defaults to 1. Exclusive with `until`. One response carries at most 50,000 periods: ten rounds at four levels, one at five.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / system / enum

Previous value: -[
-  "Vimshottari",
-  "Ashtottari",
-  "Yogini",
-  "Chara",
-  "Narayana"
-]New value: +[
+  "Vimshottari",
+  "Ashtottari",
+  "Yogini",
+  "Chara",
+  "Narayana",
+  "Sthira",
+  "NiryanaShoola",
+  "Maheshwara"
+]

addedInput schema / properties / until

Added value: +{
+  "description": "Yogini only: a horizon as a Julian Day (UT1). Whole rounds are produced until the tree reaches it, at least one and at most the maximum of `rounds`; compare the last maha's end_jd with it to see whether it was cut. Exclusive with `rounds`.",
+  "type": "number"
+}

changedOutput schema / oneOf

Previous value: -[
-  {
-    "properties": {
-      "initial_balance": {
-        "type": "number"
-      },
-      "maha_dashas": {
-        "items": {
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "moon_nakshatra": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "moon_nakshatra",
-      "initial_balance",
-      "maha_dashas"
-    ],
-    "title": "Vimshottari",
-    "type": "object"
-  },
-  {
-    "properties": {
-      "initial_balance": {
-        "type": "number"
-      },
-      "moon_nakshatra": {
-        "type": "string"
-      },
-      "periods": {
-        "items": {
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "starting_lord": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "moon_nakshatra",
-      "starting_lord",
-      "initial_balance",
-      "periods"
-    ],
-    "title": "Ashtottari",
-    "type": "object"
-  },
-  {
-    "properties": {
-      "initial_balance": {
-        "type": "number"
-      },
-      "maha_periods": {
-        "items": {
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "moon_nakshatra": {
-        "type": "string"
-      },
-      "starting_yogini_index": {
-        "type": "integer"
-      }
-    },
-    "required": [
-      "moon_nakshatra",
-      "starting_yogini_index",
-      "initial_balance",
-      "maha_periods"
-    ],
-    "title": "Yogini",
-    "type": "object"
-  },
-  {
-    "description": "Sign-based systems. Twelve single-level periods, one per rashi, in dasha order. No nakshatra or balance: these systems are anchored on the lagna and the grahas' natal signs, not the Moon.",
-    "properties": {
-      "lagna_sign": {
-        "description": "Lagna the sequence starts from, 0-11 (0 = Aries).",
-        "type": "integer"
-      },
-      "periods": {
-        "items": {
-          "properties": {
-            "duration_years": {
-              "description": "Counted from this sign to the sign its lord occupies in THIS chart, so it varies between charts.",
-              "type": "number"
-            },
-            "end_jd": {
-              "type": "number"
-            },
-            "sign_index": {
-              "type": "integer"
-            },
-            "sign_name": {
-              "type": "string"
-            },
-            "start_jd": {
-              "type": "number"
-            }
-          },
-          "required": [
-            "sign_index",
-            "sign_name",
-            "start_jd",
-            "end_jd",
-            "duration_years"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    },
-    "required": [
-      "lagna_sign",
-      "periods"
-    ],
-    "title": "Chara / Narayana",
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "maha_dashas": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "initial_balance",
+      "maha_dashas"
+    ],
+    "title": "Vimshottari",
+    "type": "object"
+  },
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      },
+      "periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "starting_lord": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "starting_lord",
+      "initial_balance",
+      "periods"
+    ],
+    "title": "Ashtottari",
+    "type": "object"
+  },
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "maha_periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      },
+      "starting_yogini_index": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "starting_yogini_index",
+      "initial_balance",
+      "maha_periods"
+    ],
+    "title": "Yogini",
+    "type": "object"
+  },
+  {
+    "description": "Sign-based systems. Twelve single-level periods, one per rashi, in dasha order. No nakshatra or balance: these systems are anchored on the lagna and the grahas' natal signs, not the Moon. With `antardashas` true, Chara's periods also carry `antar`.",
+    "properties": {
+      "lagna_sign": {
+        "description": "Lagna the sequence starts from, 0-11 (0 = Aries).",
+        "type": "integer"
+      },
+      "periods": {
+        "items": {
+          "properties": {
+            "antar": {
+              "description": "Chara with `antardashas` true only: the twelve antardashas, tiling the period.",
+              "items": {
+                "type": "object"
+              },
+              "type": "array"
+            },
+            "duration_years": {
+              "description": "Counted from this sign to the sign its lord occupies in THIS chart, so it varies between charts.",
+              "type": "number"
+            },
+            "end_jd": {
+              "type": "number"
+            },
+            "sign_index": {
+              "type": "integer"
+            },
+            "sign_name": {
+              "type": "string"
+            },
+            "start_jd": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "sign_index",
+            "sign_name",
+            "start_jd",
+            "end_jd",
+            "duration_years"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "lagna_sign",
+      "periods"
+    ],
+    "title": "Chara / Narayana",
+    "type": "object"
+  },
+  {
+    "description": "Twelve periods of 7, 8 or 9 years by modality from the Brahma graha's rashi, each with twelve antardashas. When the chart has no Brahma graha, `no_brahma` is true, `message` says so, and `anchor_sign`, `brahma` and `direction` are null and `periods` is empty: the text names no other start.",
+    "properties": {
+      "anchor_sign": {
+        "type": [
+          "integer",
+          "null"
+        ]
+      },
+      "brahma": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "direction": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "message": {
+        "type": "string"
+      },
+      "no_brahma": {
+        "type": "boolean"
+      },
+      "periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "no_brahma",
+      "anchor_sign",
+      "brahma",
+      "direction",
+      "periods"
+    ],
+    "title": "Sthira",
+    "type": "object"
+  },
+  {
+    "description": "Twelve periods of 7, 8 or 9 years in trikona groups from the stronger of the lagna and the seventh, each with twelve antardashas.",
+    "not": {
+      "required": [
+        "no_brahma"
+      ]
+    },
+    "properties": {
+      "anchor_sign": {
+        "type": "integer"
+      },
+      "direction": {
+        "type": "string"
+      },
+      "periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "anchor_sign",
+      "direction",
+      "periods"
+    ],
+    "title": "Niryana Shoola",
+    "type": "object"
+  },
+  {
+    "description": "The Maheshwara graha, the span of life to the end of its rashi's sthira period, and the antardashas of that period that can carry death. When the sthira dasha has no Brahma anchor, `no_brahma` is true with a `message`, `maheshwara` and `rashi` are still given, and the rest is absent.",
+    "properties": {
+      "death_antars": {
+        "items": {
+          "type": "integer"
+        },
+        "type": "array"
+      },
+      "death_trikona": {
+        "items": {
+          "type": "integer"
+        },
+        "type": "array"
+      },
+      "eighth_lord": {
+        "type": "string"
+      },
+      "eighth_lord_rashi": {
+        "type": "integer"
+      },
+      "life_span_years": {
+        "type": "number"
+      },
+      "maheshwara": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "no_brahma": {
+        "type": "boolean"
+      },
+      "period": {
+        "type": "object"
+      },
+      "rashi": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "no_brahma",
+      "maheshwara",
+      "rashi"
+    ],
+    "title": "Maheshwara",
+    "type": "object"
+  }
+]

Changedcompute_shadbala35 fields changed

addedInput schema / properties / ayanamsha

Added value: +{
+  "description": "Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Tropical is refused: this tool is defined on sidereal positions. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49.",
+  "enum": [
+    "IndianOfficial",
+    "FaganBradley",
+    "Krishnamurti",
+    "Raman",
+    "SuryaSiddhanta",
+    "Yukteshwar",
+    "RevatiPaksha",
+    "PushyaPaksha",
+    "TrueChitra",
+    "ChandraHari",
+    "GalacticCenter0Sag"
+  ],
+  "type": "string"
+}

addedInput schema / properties / elevation_m

Added value: +{
+  "default": 0,
+  "description": "Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise and sunset.",
+  "maximum": 9000,
+  "minimum": -500,
+  "type": "number"
+}

addedInput schema / properties / house_system

Added value: +{
+  "default": "Placidus",
+  "description": "House system whose first, fourth, seventh and tenth cusps Dig Bala is measured from, and whose house placements give Kendradi Bala: Placidus, Koch, Equal, WholeSign, etc. The same names compute_natal_chart takes.",
+  "type": "string"
+}

removedInput schema / properties / is_daytime

Removed value: -{
-  "default": false,
-  "description": "True if the birth moment falls between sunrise and sunset. Feeds Nathonnatha Bala within Kala Bala.",
-  "type": "boolean"
-}

addedInput schema / properties / julian_day

Added value: +{
+  "description": "Julian Day number in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day.",
+  "type": "number"
+}

addedInput schema / properties / latitude

Added value: +{
+  "description": "Geographic latitude in degrees, north positive. The Hindu day is reckoned from this place's sunrise.",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / longitude

Added value: +{
+  "description": "Geographic longitude in degrees, east positive.",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

removedInput schema / properties / moon_phase_waxing

Removed value: -{
-  "default": false,
-  "description": "True during shukla paksha (waxing Moon). Feeds Paksha Bala within Kala Bala.",
-  "type": "boolean"
-}

removedInput schema / properties / planets

Removed value: -{
-  "description": "Array of planet data objects.",
-  "items": {
-    "properties": {
-      "average_speed": {
-        "description": "Mean daily motion in degrees per day, compared against speed for Cheshta Bala.",
-        "type": "number"
-      },
-      "benefic_aspect_count": {
-        "default": 0,
-        "description": "Number of benefic aspects received. Drives Drik Bala.",
-        "type": "integer"
-      },
-      "bhava": {
-        "description": "House occupied, 1-12. Drives Dig Bala and Kendradi Bala.",
-        "maximum": 12,
-        "minimum": 1,
-        "type": "integer"
-      },
-      "longitude": {
-        "description": "Sidereal longitude in degrees [0, 360). Drives Uchcha, Ojhayugma and Drekkana Bala.",
-        "maximum": 360,
-        "minimum": 0,
-        "type": "number"
-      },
-      "malefic_aspect_count": {
-        "default": 0,
-        "description": "Number of malefic aspects received, subtracted in Drik Bala.",
-        "type": "integer"
-      },
-      "planet": {
-        "description": "Planet name: Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn",
-        "type": "string"
-      },
-      "sign": {
-        "description": "Sidereal sign index, which must agree with longitude (floor(longitude / 30)).",
-        "maximum": 11,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "speed": {
-        "description": "Current apparent speed in degrees per day, negative when retrograde. Drives Cheshta Bala.",
-        "type": "number"
-      }
-    },
-    "required": [
-      "planet",
-      "sign",
-      "longitude",
-      "bhava",
-      "speed",
-      "average_speed"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

addedInput schema / properties / tz_offset_minutes

Added value: +{
+  "default": 0,
+  "description": "Offset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Names the calendar date of the sunrise that begins the Hindu day, from which the lords of the year, month and day (abda, masa, vara) are reckoned.",
+  "maximum": 840,
+  "minimum": -720,
+  "type": "integer"
+}

changedInput schema / required

Previous value: -[
-  "planets"
-]New value: +[
+  "julian_day",
+  "latitude",
+  "longitude",
+  "ayanamsha"
+]

addedOutput schema / properties / cusps

Added value: +{
+  "description": "The four angular cusps Dig Bala is measured from, sidereal degrees.",
+  "properties": {
+    "first": {
+      "type": "number"
+    },
+    "fourth": {
+      "type": "number"
+    },
+    "seventh": {
+      "type": "number"
+    },
+    "tenth": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "first",
+    "fourth",
+    "seventh",
+    "tenth"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / house_system

Added value: +{
+  "description": "The house system requested. When `polar_fallback` is true it was undefined at this latitude, and the cusps and house placements come from the fallback the natal chart uses.",
+  "type": "string"
+}

addedOutput schema / properties / julian_day

Added value: +{
+  "description": "The Julian Day (UT1) the strengths were computed for, echoed back.",
+  "type": "number"
+}

addedOutput schema / properties / moment

Added value: +{
+  "description": "The birth moment Kala Bala was reckoned from. Every instant is a Julian Day (UT1).",
+  "properties": {
+    "apparent_hours_from_midnight": {
+      "description": "Local apparent solar time, hours since midnight, 0 to 24: the hour angle of the true Sun plus 12 hours.",
+      "type": "number"
+    },
+    "hindu_day_jdn": {
+      "description": "Julian Day Number of the local calendar date of jd_sunrise, at tz_offset_minutes.",
+      "type": "integer"
+    },
+    "jd": {
+      "description": "The birth.",
+      "type": "number"
+    },
+    "jd_next_sunrise": {
+      "description": "The sunrise that ends the Hindu day.",
+      "type": "number"
+    },
+    "jd_sunrise": {
+      "description": "The sunrise that begins the Hindu day holding the birth: the last at or before it.",
+      "type": "number"
+    },
+    "jd_sunset": {
+      "description": "The sunset of that day.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "jd",
+    "jd_sunrise",
+    "jd_sunset",
+    "jd_next_sunrise",
+    "hindu_day_jdn",
+    "apparent_hours_from_midnight"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / planets / description

Previous value: -"One entry per graha supplied, in input order."New value: +"The seven grahas, Sun to Saturn, in the order Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn. All strengths are in virupas."

changedOutput schema / properties / planets / items / properties / cheshta_bala / description

Previous value: -"Motional strength, from speed against average speed."New value: +"Motional strength: the Sun's ayana bala, the Moon's paksha bala, the folded cheshta kendra over 3 for the others (27.18, 27.24, 27.25)."

changedOutput schema / properties / planets / items / properties / dig_bala / description

Previous value: -"Directional strength."New value: +"Directional strength, 0-60, continuous in the longitude (27.7)."

removedOutput schema / properties / planets / items / properties / drekkana_bala

Removed value: -{
-  "description": "Decanate strength, 0 or 15.",
-  "type": "number"
-}

changedOutput schema / properties / planets / items / properties / drik_bala / description

Previous value: -"Aspectual strength, benefic aspects minus malefic."New value: +"Aspectual strength from the sphuta drishti, signed (27.19)."

changedOutput schema / properties / planets / items / properties / ishta_phala / description

Previous value: -"Benefic potential, 0-60."New value: +"Benefic potential, 0-60 (28.5-28.6)."

addedOutput schema / properties / planets / items / properties / kala

Added value: +{
+  "description": "Temporal strength by part.",
+  "properties": {
+    "abda": {
+      "description": "15 to the lord of the year (27.13).",
+      "type": "number"
+    },
+    "ayana": {
+      "description": "Strength from the sayana longitude, 0-60 (27.15-27.17), undoubled.",
+      "type": "number"
+    },
+    "hora": {
+      "description": "60 to the lord of the hora.",
+      "type": "number"
+    },
+    "masa": {
+      "description": "30 to the lord of the month.",
+      "type": "number"
+    },
+    "nathonnata": {
+      "description": "Day/night strength from the time from local midnight, 0-60 (27.8-27.9).",
+      "type": "number"
+    },
+    "paksha": {
+      "description": "Strength from the Moon-Sun elongation, 0-60 (27.10-27.11), undoubled for the Moon.",
+      "type": "number"
+    },
+    "total": {
+      "description": "Sum of the nine.",
+      "type": "number"
+    },
+    "tribhaga": {
+      "description": "60 to Jupiter and to the lord of the third of the day or night (27.12).",
+      "type": "number"
+    },
+    "vara": {
+      "description": "45 to the lord of the day.",
+      "type": "number"
+    },
+    "yuddha": {
+      "description": "Signed planetary-war adjustment (27.20): the difference of the two strengths to the victor, from the vanquished.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "nathonnata",
+    "paksha",
+    "tribhaga",
+    "abda",
+    "masa",
+    "vara",
+    "hora",
+    "ayana",
+    "yuddha",
+    "total"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / planets / items / properties / kala_bala

Removed value: -{
-  "description": "Temporal strength. Nathonnatha and Paksha only; see the tool description.",
-  "type": "number"
-}

removedOutput schema / properties / planets / items / properties / kendradi_bala

Removed value: -{
-  "description": "Angularity strength, 15-60.",
-  "type": "number"
-}

addedOutput schema / properties / planets / items / properties / motion

Added value: +{
+  "description": "The graha's motion state (27.21-27.23). Reported beside the strengths and not part of any total.",
+  "properties": {
+    "mean_speed_deg_per_day": {
+      "description": "Mean geocentric motion at the birth, the pace the state is judged against.",
+      "type": "number"
+    },
+    "speed_deg_per_day": {
+      "description": "Speed in longitude, negative when retrograde.",
+      "type": "number"
+    },
+    "state": {
+      "description": "Vakra, Anuvakra, Vikala, Manda, Mandatara, Sama, Chara or Atichara.",
+      "type": "string"
+    },
+    "virupas": {
+      "description": "The cheshta bala that state carries in the verse.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "state",
+    "virupas",
+    "speed_deg_per_day",
+    "mean_speed_deg_per_day"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / planets / items / properties / naisargika_bala / description

Previous value: -"Natural strength, fixed per graha."New value: +"Natural strength, fixed per graha (27.14)."

removedOutput schema / properties / planets / items / properties / ojhayugma_bala

Removed value: -{
-  "description": "Odd/even sign strength, 0-30.",
-  "type": "number"
-}

addedOutput schema / properties / planets / items / properties / sthana

Added value: +{
+  "description": "Positional strength by part.",
+  "properties": {
+    "drekkana": {
+      "description": "Decanate strength, 0 or 15 (27.6).",
+      "type": "number"
+    },
+    "kendradi": {
+      "description": "Angularity strength from the house, 15, 30 or 60.",
+      "type": "number"
+    },
+    "ojhayugma": {
+      "description": "Odd/even sign and navamsa strength, 0-30.",
+      "type": "number"
+    },
+    "saptavargaja": {
+      "description": "Dignity in the seven vargas D1, D2, D3, D7, D9, D12 and D30 (27.2-27.4).",
+      "type": "number"
+    },
+    "total": {
+      "description": "Sum of the five.",
+      "type": "number"
+    },
+    "uccha": {
+      "description": "Exaltation strength, 0-60 (27.1).",
+      "type": "number"
+    }
+  },
+  "required": [
+    "uccha",
+    "saptavargaja",
+    "ojhayugma",
+    "kendradi",
+    "drekkana",
+    "total"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / planets / items / properties / sthana_bala

Removed value: -{
-  "description": "Positional strength: the sum of the four sub-components below.",
-  "type": "number"
-}

changedOutput schema / properties / planets / items / properties / total / description

Previous value: -"Sum of the six balas, in virupas."New value: +"Sum of the six: sthana.total + dig_bala + kala.total + cheshta_bala + naisargika_bala + drik_bala."

removedOutput schema / properties / planets / items / properties / uccha_bala

Removed value: -{
-  "description": "Exaltation strength, 0-60.",
-  "type": "number"
-}

changedOutput schema / properties / planets / items / required

Previous value: -[
-  "planet",
-  "sthana_bala",
-  "dig_bala",
-  "kala_bala",
-  "cheshta_bala",
-  "naisargika_bala",
-  "drik_bala",
-  "total"
-]New value: +[
+  "planet",
+  "sthana",
+  "dig_bala",
+  "kala",
+  "cheshta_bala",
+  "naisargika_bala",
+  "drik_bala",
+  "total",
+  "ishta_phala",
+  "kashta_phala",
+  "motion"
+]

addedOutput schema / properties / polar_fallback

Added value: +{
+  "description": "True when the requested house system was undefined at this latitude and a fallback was used, so Dig Bala and Kendradi Bala are read from the fallback's cusps and houses.",
+  "type": "boolean"
+}

addedOutput schema / properties / true_ayanamsha_value

Added value: +{
+  "description": "True ayanamsha (mean plus nutation in longitude) applied, in degrees.",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "planets"
-]New value: +[
+  "julian_day",
+  "true_ayanamsha_value",
+  "house_system",
+  "polar_fallback",
+  "moment",
+  "cusps",
+  "planets"
+]

1 tool updatev9.1.2Sep 15, 2026

Changedcompute_combustion4 fields changed

changedInput schema / properties / mars_retrograde / description

Previous value: -"True if Mars is retrograde, which narrows its combustion orb from 17 deg to 8 deg. From compute_natal_chart's Mars entry, field retrograde."New value: +"True if Mars is retrograde. Accepted for symmetry; Mars's orb is 17 deg either way (Surya Siddhanta IX.6 gives it no retrograde figure), so this does not change the result. From compute_natal_chart's Mars entry, field retrograde."

changedInput schema / properties / mercury_retrograde / description

Previous value: -"True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (BPHS Ch. 7 vv. 28-29). From compute_natal_chart's Mercury entry, field retrograde."New value: +"True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (Surya Siddhanta IX.8). From compute_natal_chart's Mercury entry, field retrograde."

changedInput schema / properties / saturn_retrograde / description

Previous value: -"True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 16 deg either way, so this does not change the result. From compute_natal_chart's Saturn entry, field retrograde."New value: +"True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 15 deg either way, so this does not change the result. From compute_natal_chart's Saturn entry, field retrograde."

changedInput schema / properties / venus_retrograde / description

Previous value: -"True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg. From compute_natal_chart's Venus entry, field retrograde."New value: +"True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg (Surya Siddhanta IX.7). From compute_natal_chart's Venus entry, field retrograde."

4 tool updatesv8.0.1Sep 3, 2026

Changedcompute_combustion12 fields changed

changedInput schema / properties / jupiter / description

Previous value: -"Sidereal longitude of Jupiter [0, 360)"New value: +"Sidereal longitude of Jupiter [0, 360). From compute_natal_chart's planets[] entry where name == \"Jupiter\", field longitude."

changedInput schema / properties / jupiter_retrograde / description

Previous value: -"True if Jupiter is retrograde. Accepted for symmetry; Jupiter's orb is 11 deg either way, so this does not change the result"New value: +"True if Jupiter is retrograde. Accepted for symmetry; Jupiter's orb is 11 deg either way, so this does not change the result. From compute_natal_chart's Jupiter entry, field retrograde."

changedInput schema / properties / mars / description

Previous value: -"Sidereal longitude of Mars [0, 360)"New value: +"Sidereal longitude of Mars [0, 360). From compute_natal_chart's planets[] entry where name == \"Mars\", field longitude."

changedInput schema / properties / mars_retrograde / description

Previous value: -"True if Mars is retrograde, which narrows its combustion orb from 17 deg to 8 deg"New value: +"True if Mars is retrograde, which narrows its combustion orb from 17 deg to 8 deg. From compute_natal_chart's Mars entry, field retrograde."

changedInput schema / properties / mercury / description

Previous value: -"Sidereal longitude of Mercury [0, 360)"New value: +"Sidereal longitude of Mercury [0, 360). From compute_natal_chart's planets[] entry where name == \"Mercury\", field longitude."

changedInput schema / properties / mercury_retrograde / description

Previous value: -"True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (BPHS Ch. 7 vv. 28-29)"New value: +"True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (BPHS Ch. 7 vv. 28-29). From compute_natal_chart's Mercury entry, field retrograde."

changedInput schema / properties / moon / description

Previous value: -"Sidereal longitude of Moon [0, 360)"New value: +"Sidereal longitude of Moon [0, 360). From compute_natal_chart's planets[] entry where name == \"Moon\", field longitude."

changedInput schema / properties / saturn / description

Previous value: -"Sidereal longitude of Saturn [0, 360)"New value: +"Sidereal longitude of Saturn [0, 360). From compute_natal_chart's planets[] entry where name == \"Saturn\", field longitude."

changedInput schema / properties / saturn_retrograde / description

Previous value: -"True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 16 deg either way, so this does not change the result"New value: +"True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 16 deg either way, so this does not change the result. From compute_natal_chart's Saturn entry, field retrograde."

changedInput schema / properties / sun / description

Previous value: -"Sidereal longitude of Sun [0, 360)"New value: +"Sidereal longitude of Sun [0, 360). From compute_natal_chart's planets[] entry where name == \"Sun\", field longitude."

changedInput schema / properties / venus / description

Previous value: -"Sidereal longitude of Venus [0, 360)"New value: +"Sidereal longitude of Venus [0, 360). From compute_natal_chart's planets[] entry where name == \"Venus\", field longitude."

changedInput schema / properties / venus_retrograde / description

Previous value: -"True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg"New value: +"True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg. From compute_natal_chart's Venus entry, field retrograde."

Changedcompute_dasha9 fields changed

changedInput schema / properties / birth_jd / description

Previous value: -"Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. Dasha computation is ephemeris-free, so this epoch is carried through rather than converted: every returned start_jd/end_jd is on the same UT1 scale as the input."New value: +"Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. This epoch is only added to, never converted: every returned start_jd/end_jd is on the same UT1 scale as the input."

addedInput schema / properties / graha_signs

Added value: +{
+  "description": "Natal sign positions of the seven classical grahas plus Rahu, 0-11 each (0 = Aries), as served by compute_natal_chart's sign_index. Required for Chara, Narayana, whose period lengths are chart-dependent — each sign's duration is the count from that sign to the sign its lord actually occupies. Sign indices are used rather than longitudes: they chain directly from compute_natal_chart's sign_index with no conversion, carry no tropical-vs-sidereal ambiguity, and avoid the boundary question of a planet at exactly 30.0 degrees. Ketu is not a field: it is derived as (rahu + 6) mod 12, since the two lunar nodes are always exactly opposite.",
+  "properties": {
+    "jupiter": {
+      "description": "Jupiter's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "mars": {
+      "description": "Mars's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "mercury": {
+      "description": "Mercury's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "moon": {
+      "description": "Moon's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "rahu": {
+      "description": "Rahu's (north lunar node's) natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "saturn": {
+      "description": "Saturn's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "sun": {
+      "description": "Sun's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "venus": {
+      "description": "Venus's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "sun",
+    "moon",
+    "mars",
+    "mercury",
+    "jupiter",
+    "venus",
+    "saturn",
+    "rahu"
+  ],
+  "type": "object"
+}

changedInput schema / properties / lagna_sign / description

Previous value: -"Lagna (ascendant) sign 1–12 (1 = Aries). Required for Chara, Narayana."New value: +"Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here."

changedInput schema / properties / lagna_sign / maximum
```
Previous value: -12New value: +11
```
changedInput schema / properties / lagna_sign / minimum
```
Previous value: -1New value: +0
```

addedOutput schema / description

Added value: +"Envelope depends on `system`; see the four variants below. Every period carries start_jd/end_jd on the same UT1 scale as birth_jd."

addedOutput schema / oneOf

Added value: +[
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "maha_dashas": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "initial_balance",
+      "maha_dashas"
+    ],
+    "title": "Vimshottari",
+    "type": "object"
+  },
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      },
+      "periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "starting_lord": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "starting_lord",
+      "initial_balance",
+      "periods"
+    ],
+    "title": "Ashtottari",
+    "type": "object"
+  },
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "maha_periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      },
+      "starting_yogini_index": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "starting_yogini_index",
+      "initial_balance",
+      "maha_periods"
+    ],
+    "title": "Yogini",
+    "type": "object"
+  },
+  {
+    "description": "Sign-based systems. Twelve single-level periods, one per rashi, in dasha order. No nakshatra or balance: these systems are anchored on the lagna and the grahas' natal signs, not the Moon.",
+    "properties": {
+      "lagna_sign": {
+        "description": "Lagna the sequence starts from, 0-11 (0 = Aries).",
+        "type": "integer"
+      },
+      "periods": {
+        "items": {
+          "properties": {
+            "duration_years": {
+              "description": "Counted from this sign to the sign its lord occupies in THIS chart, so it varies between charts.",
+              "type": "number"
+            },
+            "end_jd": {
+              "type": "number"
+            },
+            "sign_index": {
+              "type": "integer"
+            },
+            "sign_name": {
+              "type": "string"
+            },
+            "start_jd": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "sign_index",
+            "sign_name",
+            "start_jd",
+            "end_jd",
+            "duration_years"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "lagna_sign",
+      "periods"
+    ],
+    "title": "Chara / Narayana",
+    "type": "object"
+  }
+]

removedOutput schema / properties

Removed value: -{
-  "initial_balance": {
-    "description": "Fraction of the first mahadasha already elapsed at birth, in [0, 1).",
-    "type": "number"
-  },
-  "maha_dashas": {
-    "items": {
-      "properties": {
-        "duration_days": {
-          "description": "Length of the period in days.",
-          "type": "number"
-        },
-        "end_jd": {
-          "description": "End of the period as a Julian Day.",
-          "type": "number"
-        },
-        "level": {
-          "description": "Nesting depth: 1 = mahadasha, 2 = antardasha, 3 = pratyantardasha.",
-          "type": "integer"
-        },
-        "lord": {
-          "description": "Ruling graha of the period.",
-          "type": "string"
-        },
-        "start_jd": {
-          "description": "Start of the period as a Julian Day.",
-          "type": "number"
-        },
-        "sub_periods": {
-          "description": "Nested periods one level down; empty at the deepest level requested.",
-          "items": {
-            "type": "object"
-          },
-          "type": "array"
-        }
-      },
-      "required": [
-        "lord",
-        "level",
-        "start_jd",
-        "end_jd",
-        "duration_days"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "moon_nakshatra": {
-    "description": "Birth nakshatra of the Moon, which sets the starting mahadasha.",
-    "type": "string"
-  }
-}

removedOutput schema / required

Removed value: -[
-  "moon_nakshatra",
-  "initial_balance",
-  "maha_dashas"
-]

Changedcompute_natal_chart3 fields changed

changedInput schema / properties / ayanamsha / description

Previous value: -"Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."New value: +"Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."

removedOutput schema / properties / ayanamsha_value

Removed value: -{
-  "description": "True ayanamsha (mean plus nutation in longitude) applied, in degrees. Zero for a tropical chart.",
-  "type": "number"
-}

addedOutput schema / properties / true_ayanamsha_value

Added value: +{
+  "description": "True ayanamsha (mean plus nutation in longitude) applied, in degrees. Zero for a tropical chart.",
+  "type": "number"
+}

Changedcompute_vargas3 fields changed

changedInput schema / properties / ayanamsha / description

Previous value: -"Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."New value: +"Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."

removedOutput schema / properties / ayanamsha_value

Removed value: -{
-  "description": "True ayanamsha (mean plus nutation in longitude) applied before dividing, in degrees. Zero when Tropical.",
-  "type": "number"
-}

addedOutput schema / properties / true_ayanamsha_value

Added value: +{
+  "description": "True ayanamsha (mean plus nutation in longitude) applied before dividing, in degrees. Zero when Tropical.",
+  "type": "number"
+}

16 tool updatesv8.0.0Aug 29, 2026

Changedcompute_ashtakavarga7 fields changed

addedInput schema / properties / jupiter / description

Added value: +"Sign index of Jupiter (0=Aries…11=Pisces)"

addedInput schema / properties / mars / description

Added value: +"Sign index of Mars (0=Aries…11=Pisces)"

addedInput schema / properties / mercury / description

Added value: +"Sign index of Mercury (0=Aries…11=Pisces)"

addedInput schema / properties / moon / description

Added value: +"Sign index of Moon (0=Aries…11=Pisces)"

addedInput schema / properties / saturn / description

Added value: +"Sign index of Saturn (0=Aries…11=Pisces)"

addedInput schema / properties / venus / description

Added value: +"Sign index of Venus (0=Aries…11=Pisces)"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "sarvashtakavarga": {
+      "description": "Twelve entries, Aries first.",
+      "items": {
+        "description": "Summed bindus in one rashi.",
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    "tables": {
+      "description": "One Bhinna Ashtakavarga per graha.",
+      "items": {
+        "properties": {
+          "bindus": {
+            "description": "Twelve entries, Aries first.",
+            "items": {
+              "description": "Bindus in one rashi, 0-8.",
+              "type": "integer"
+            },
+            "type": "array"
+          },
+          "planet": {
+            "description": "Graha whose Bhinna Ashtakavarga this is.",
+            "type": "string"
+          },
+          "total": {
+            "description": "Sum of this graha's bindus.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "planet",
+          "bindus",
+          "total"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "tables",
+    "sarvashtakavarga"
+  ],
+  "type": "object"
+}

Changedcompute_bhavas1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "houses": {
+      "description": "Twelve entries in order.",
+      "items": {
+        "properties": {
+          "bhava": {
+            "description": "House number, 1-12.",
+            "type": "integer"
+          },
+          "is_dusthana": {
+            "description": "True for houses 6, 8, 12.",
+            "type": "boolean"
+          },
+          "is_kendra": {
+            "description": "True for houses 1, 4, 7, 10.",
+            "type": "boolean"
+          },
+          "is_trikona": {
+            "description": "True for houses 1, 5, 9.",
+            "type": "boolean"
+          },
+          "is_upachaya": {
+            "description": "True for houses 3, 6, 10, 11.",
+            "type": "boolean"
+          },
+          "sign": {
+            "description": "Rashi occupying it, 0=Aries … 11=Pisces.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "bhava",
+          "sign"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "lagna_sign": {
+      "description": "Rashi of the ascendant, 0=Aries … 11=Pisces.",
+      "type": "integer"
+    },
+    "planets": {
+      "description": "Empty unless grahas were supplied.",
+      "items": {
+        "properties": {
+          "bhava": {
+            "description": "House the graha falls in, 1-12.",
+            "type": "integer"
+          },
+          "longitude": {
+            "description": "Sidereal longitude in degrees [0, 360).",
+            "type": "number"
+          },
+          "planet": {
+            "description": "Graha name as supplied.",
+            "type": "string"
+          },
+          "sign": {
+            "description": "Rashi it occupies, 0=Aries … 11=Pisces.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "planet",
+          "bhava"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "lagna_sign",
+    "houses"
+  ],
+  "type": "object"
+}

Changedcompute_combustion6 fields changed

addedInput schema / properties / jupiter_retrograde / description

Added value: +"True if Jupiter is retrograde. Accepted for symmetry; Jupiter's orb is 11 deg either way, so this does not change the result"

addedInput schema / properties / mars_retrograde / description

Added value: +"True if Mars is retrograde, which narrows its combustion orb from 17 deg to 8 deg"

addedInput schema / properties / mercury_retrograde / description

Added value: +"True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (BPHS Ch. 7 vv. 28-29)"

addedInput schema / properties / saturn_retrograde / description

Added value: +"True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 16 deg either way, so this does not change the result"

addedInput schema / properties / venus_retrograde / description

Added value: +"True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "states": {
+      "description": "One entry per graha other than the Sun.",
+      "items": {
+        "properties": {
+          "degrees_from_sun": {
+            "description": "Angular separation from the Sun in degrees.",
+            "type": "number"
+          },
+          "planet": {
+            "description": "Graha assessed.",
+            "type": "string"
+          },
+          "state": {
+            "description": "Combust, DeeplyCombust, or None.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "planet",
+          "state",
+          "degrees_from_sun"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "states"
+  ],
+  "type": "object"
+}

Changedcompute_composite1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "planets": {
+      "description": "One entry per graha present in both charts.",
+      "items": {
+        "properties": {
+          "longitude": {
+            "description": "Midpoint longitude in degrees [0, 360).",
+            "type": "number"
+          },
+          "planet": {
+            "description": "Graha name.",
+            "type": "string"
+          },
+          "speed": {
+            "description": "Mean of the two supplied speeds, in degrees per day.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "planet",
+          "longitude",
+          "speed"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "planets"
+  ],
+  "type": "object"
+}

Changedcompute_dasha1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "initial_balance": {
+      "description": "Fraction of the first mahadasha already elapsed at birth, in [0, 1).",
+      "type": "number"
+    },
+    "maha_dashas": {
+      "items": {
+        "properties": {
+          "duration_days": {
+            "description": "Length of the period in days.",
+            "type": "number"
+          },
+          "end_jd": {
+            "description": "End of the period as a Julian Day.",
+            "type": "number"
+          },
+          "level": {
+            "description": "Nesting depth: 1 = mahadasha, 2 = antardasha, 3 = pratyantardasha.",
+            "type": "integer"
+          },
+          "lord": {
+            "description": "Ruling graha of the period.",
+            "type": "string"
+          },
+          "start_jd": {
+            "description": "Start of the period as a Julian Day.",
+            "type": "number"
+          },
+          "sub_periods": {
+            "description": "Nested periods one level down; empty at the deepest level requested.",
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "lord",
+          "level",
+          "start_jd",
+          "end_jd",
+          "duration_days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "moon_nakshatra": {
+      "description": "Birth nakshatra of the Moon, which sets the starting mahadasha.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "moon_nakshatra",
+    "initial_balance",
+    "maha_dashas"
+  ],
+  "type": "object"
+}

Changedcompute_drishti1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "aspects": {
+      "items": {
+        "properties": {
+          "aspected_sign": {
+            "description": "Rashi receiving the drishti.",
+            "type": "integer"
+          },
+          "aspecting_planet": {
+            "description": "Graha casting the drishti.",
+            "type": "string"
+          },
+          "aspecting_sign": {
+            "description": "Rashi it occupies, 0=Aries … 11=Pisces.",
+            "type": "integer"
+          },
+          "houses_away": {
+            "description": "Count from the aspecting rashi, 1-12.",
+            "type": "integer"
+          },
+          "strength": {
+            "description": "Classical share cast: Full, ThreeQuarter, Half or Quarter.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "aspecting_planet",
+          "aspecting_sign",
+          "aspected_sign",
+          "houses_away",
+          "strength"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "aspects"
+  ],
+  "type": "object"
+}

Changedcompute_gochara1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "entries": {
+      "items": {
+        "properties": {
+          "classical_effect": {
+            "description": "Classical result attributed to this placement.",
+            "type": "string"
+          },
+          "graha": {
+            "description": "Transiting graha.",
+            "type": "string"
+          },
+          "house_from_natal": {
+            "description": "Count from the reference rashi, 1-12.",
+            "type": "integer"
+          },
+          "natal_reference_rashi": {
+            "description": "Rashi the count is taken from.",
+            "type": "integer"
+          },
+          "transit_rashi": {
+            "description": "Rashi the graha transits, 0=Aries … 11=Pisces.",
+            "type": "integer"
+          },
+          "vedha_candidates": {
+            "items": {
+              "description": "Graha whose placement would obstruct this effect.",
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "graha",
+          "transit_rashi",
+          "house_from_natal",
+          "classical_effect"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "entries"
+  ],
+  "type": "object"
+}

Changedcompute_karakas1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "karakas": {
+      "description": "One entry per graha, ordered by rank.",
+      "items": {
+        "properties": {
+          "degrees_in_sign": {
+            "description": "Degrees within the occupied sign, which is what ranks the grahas.",
+            "type": "number"
+          },
+          "karaka": {
+            "description": "Chara karaka title, Atmakaraka through Darakaraka.",
+            "type": "string"
+          },
+          "planet": {
+            "description": "Graha holding this karaka.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "planet",
+          "karaka",
+          "degrees_in_sign"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "karakas"
+  ],
+  "type": "object"
+}

Changedcompute_natal_chart2 fields changed

changedInput schema / properties / ayanamsha / description

Previous value: -"Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. Returns the MEAN ayanamsha - add nutation in longitude yourself for the true ayanamsha. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."New value: +"Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "aspects": {
+      "items": {
+        "properties": {
+          "applying": {
+            "description": "True when the aspect is closing rather than separating.",
+            "type": "boolean"
+          },
+          "body1": {
+            "description": "Index of the first body in the planets array.",
+            "type": "integer"
+          },
+          "body2": {
+            "description": "Index of the second body.",
+            "type": "integer"
+          },
+          "orb": {
+            "description": "Orb in degrees.",
+            "type": "number"
+          },
+          "strength": {
+            "description": "Normalised strength in [0, 1], 1 at exact.",
+            "type": "number"
+          },
+          "type": {
+            "description": "Aspect name.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "body1",
+          "body2",
+          "type",
+          "orb"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "ayanamsha_value": {
+      "description": "True ayanamsha (mean plus nutation in longitude) applied, in degrees. Zero for a tropical chart.",
+      "type": "number"
+    },
+    "config_summary": {
+      "description": "One-line record of the ephemeris, house system and ayanamsha used.",
+      "type": "string"
+    },
+    "houses": {
+      "properties": {
+        "asc": {
+          "description": "Ascendant longitude in degrees.",
+          "type": "number"
+        },
+        "cusps": {
+          "description": "Twelve cusp longitudes.",
+          "items": {
+            "description": "Cusp longitude in degrees.",
+            "type": "number"
+          },
+          "type": "array"
+        },
+        "mc": {
+          "description": "Midheaven longitude in degrees.",
+          "type": "number"
+        },
+        "polar_fallback": {
+          "description": "True when the requested system was undefined at this latitude and a fallback was used.",
+          "type": "boolean"
+        },
+        "system": {
+          "description": "House system used.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "system",
+        "asc",
+        "mc",
+        "cusps"
+      ],
+      "type": "object"
+    },
+    "julian_day": {
+      "description": "The Julian Day the chart was cast for, echoed back.",
+      "type": "number"
+    },
+    "planets": {
+      "description": "One entry per computed body.",
+      "items": {
+        "properties": {
+          "dignity": {
+            "description": "Dignity in the occupied sign, e.g. Exalted, Own, Debilitated, Neutral.",
+            "type": "string"
+          },
+          "distance": {
+            "description": "Distance from the observer in AU.",
+            "type": "number"
+          },
+          "house": {
+            "description": "Bhava occupied, 1-12.",
+            "type": "integer"
+          },
+          "latitude": {
+            "description": "Ecliptic latitude in degrees.",
+            "type": "number"
+          },
+          "longitude": {
+            "description": "Sidereal longitude in degrees [0, 360).",
+            "type": "number"
+          },
+          "name": {
+            "description": "Graha name.",
+            "type": "string"
+          },
+          "retrograde": {
+            "description": "True when speed is negative.",
+            "type": "boolean"
+          },
+          "sign": {
+            "description": "Rashi name.",
+            "type": "string"
+          },
+          "sign_index": {
+            "description": "Rashi index, 0=Aries … 11=Pisces.",
+            "type": "integer"
+          },
+          "speed": {
+            "description": "Daily motion in degrees per day, negative when retrograde.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "name",
+          "longitude",
+          "sign_index",
+          "house"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "julian_day",
+    "planets",
+    "houses",
+    "aspects"
+  ],
+  "type": "object"
+}

Changedcompute_panchanga1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "karana": {
+      "properties": {
+        "index": {
+          "description": "Karana index.",
+          "type": "integer"
+        },
+        "is_fixed": {
+          "description": "True for the four fixed karanas.",
+          "type": "boolean"
+        },
+        "name": {
+          "description": "Karana name.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "index",
+        "name"
+      ],
+      "type": "object"
+    },
+    "nakshatra": {
+      "properties": {
+        "index": {
+          "description": "Nakshatra index, 0-26.",
+          "type": "integer"
+        },
+        "name": {
+          "description": "Nakshatra name.",
+          "type": "string"
+        },
+        "pada": {
+          "description": "Pada within the nakshatra, 1-4.",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "index",
+        "name",
+        "pada"
+      ],
+      "type": "object"
+    },
+    "tithi": {
+      "properties": {
+        "lord": {
+          "description": "Ruling graha.",
+          "type": "string"
+        },
+        "name": {
+          "description": "Tithi name.",
+          "type": "string"
+        },
+        "number": {
+          "description": "Tithi number, 1-30.",
+          "type": "integer"
+        },
+        "paksha": {
+          "description": "Shukla or Krishna.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "number",
+        "name",
+        "paksha"
+      ],
+      "type": "object"
+    },
+    "vara": {
+      "properties": {
+        "from_sunrise": {
+          "description": "True when the vara was reckoned from sunrise rather than midnight.",
+          "type": "boolean"
+        },
+        "gulika_kalam": {
+          "properties": {
+            "end_jd": {
+              "description": "End as a Julian Day.",
+              "type": "number"
+            },
+            "start_jd": {
+              "description": "Start as a Julian Day.",
+              "type": "number"
+            }
+          },
+          "type": "object"
+        },
+        "gulika_kalam_slot": {
+          "description": "Which eighth of the day Gulika Kalam falls in, 1-8.",
+          "type": "integer"
+        },
+        "lord": {
+          "description": "Ruling graha.",
+          "type": "string"
+        },
+        "rahu_kalam": {
+          "properties": {
+            "end_jd": {
+              "description": "End as a Julian Day.",
+              "type": "number"
+            },
+            "start_jd": {
+              "description": "Start as a Julian Day.",
+              "type": "number"
+            }
+          },
+          "type": "object"
+        },
+        "rahu_kalam_slot": {
+          "description": "Which eighth of the day Rahu Kalam falls in, 1-8.",
+          "type": "integer"
+        },
+        "weekday": {
+          "description": "Vara name.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "weekday",
+        "lord"
+      ],
+      "type": "object"
+    },
+    "yoga": {
+      "properties": {
+        "index": {
+          "description": "Yoga index, 0-26.",
+          "type": "integer"
+        },
+        "name": {
+          "description": "Yoga name.",
+          "type": "string"
+        },
+        "remaining_degrees": {
+          "description": "Degrees left before the yoga changes.",
+          "type": "number"
+        }
+      },
+      "required": [
+        "index",
+        "name"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "tithi",
+    "vara",
+    "nakshatra",
+    "yoga",
+    "karana"
+  ],
+  "type": "object"
+}

Changedcompute_shadbala10 fields changed

addedInput schema / properties / is_daytime / description

Added value: +"True if the birth moment falls between sunrise and sunset. Feeds Nathonnatha Bala within Kala Bala."

addedInput schema / properties / moon_phase_waxing / description

Added value: +"True during shukla paksha (waxing Moon). Feeds Paksha Bala within Kala Bala."

addedInput schema / properties / planets / items / properties / average_speed / description

Added value: +"Mean daily motion in degrees per day, compared against speed for Cheshta Bala."

addedInput schema / properties / planets / items / properties / benefic_aspect_count / description
```
Added value: +"Number of benefic aspects received. Drives Drik Bala."
```
addedInput schema / properties / planets / items / properties / bhava / description
```
Added value: +"House occupied, 1-12. Drives Dig Bala and Kendradi Bala."
```

addedInput schema / properties / planets / items / properties / longitude / description

Added value: +"Sidereal longitude in degrees [0, 360). Drives Uchcha, Ojhayugma and Drekkana Bala."

addedInput schema / properties / planets / items / properties / malefic_aspect_count / description
```
Added value: +"Number of malefic aspects received, subtracted in Drik Bala."
```

addedInput schema / properties / planets / items / properties / sign / description

Added value: +"Sidereal sign index, which must agree with longitude (floor(longitude / 30))."

addedInput schema / properties / planets / items / properties / speed / description

Added value: +"Current apparent speed in degrees per day, negative when retrograde. Drives Cheshta Bala."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "planets": {
+      "description": "One entry per graha supplied, in input order.",
+      "items": {
+        "properties": {
+          "cheshta_bala": {
+            "description": "Motional strength, from speed against average speed.",
+            "type": "number"
+          },
+          "dig_bala": {
+            "description": "Directional strength.",
+            "type": "number"
+          },
+          "drekkana_bala": {
+            "description": "Decanate strength, 0 or 15.",
+            "type": "number"
+          },
+          "drik_bala": {
+            "description": "Aspectual strength, benefic aspects minus malefic.",
+            "type": "number"
+          },
+          "ishta_phala": {
+            "description": "Benefic potential, 0-60.",
+            "type": "number"
+          },
+          "kala_bala": {
+            "description": "Temporal strength. Nathonnatha and Paksha only; see the tool description.",
+            "type": "number"
+          },
+          "kashta_phala": {
+            "description": "Malefic potential, 0-60.",
+            "type": "number"
+          },
+          "kendradi_bala": {
+            "description": "Angularity strength, 15-60.",
+            "type": "number"
+          },
+          "naisargika_bala": {
+            "description": "Natural strength, fixed per graha.",
+            "type": "number"
+          },
+          "ojhayugma_bala": {
+            "description": "Odd/even sign strength, 0-30.",
+            "type": "number"
+          },
+          "planet": {
+            "description": "Graha assessed.",
+            "type": "string"
+          },
+          "sthana_bala": {
+            "description": "Positional strength: the sum of the four sub-components below.",
+            "type": "number"
+          },
+          "total": {
+            "description": "Sum of the six balas, in virupas.",
+            "type": "number"
+          },
+          "uccha_bala": {
+            "description": "Exaltation strength, 0-60.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "planet",
+          "sthana_bala",
+          "dig_bala",
+          "kala_bala",
+          "cheshta_bala",
+          "naisargika_bala",
+          "drik_bala",
+          "total"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "planets"
+  ],
+  "type": "object"
+}

Changedcompute_synastry1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "aspects": {
+      "items": {
+        "properties": {
+          "aspect_type": {
+            "description": "Aspect name.",
+            "type": "string"
+          },
+          "chart_a_planet": {
+            "description": "Graha from the first chart.",
+            "type": "string"
+          },
+          "chart_b_planet": {
+            "description": "Graha from the second chart.",
+            "type": "string"
+          },
+          "orb": {
+            "description": "Departure from exact, in degrees.",
+            "type": "number"
+          },
+          "strength": {
+            "description": "Normalised strength in [0, 1], 1 at exact.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "chart_a_planet",
+          "chart_b_planet",
+          "aspect_type",
+          "orb",
+          "strength"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "aspects"
+  ],
+  "type": "object"
+}

Changedcompute_transit1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "natal_jd": {
+      "description": "Julian Day of the natal chart, echoed back.",
+      "type": "number"
+    },
+    "natal_positions": {
+      "description": "Natal positions used for the comparison.",
+      "items": {
+        "properties": {
+          "distance": {
+            "description": "Distance from the observer in AU.",
+            "type": "number"
+          },
+          "latitude": {
+            "description": "Ecliptic latitude in degrees.",
+            "type": "number"
+          },
+          "longitude": {
+            "description": "Longitude in degrees [0, 360), sidereal when an ayanamsha was applied.",
+            "type": "number"
+          },
+          "name": {
+            "description": "Body name.",
+            "type": "string"
+          },
+          "speed": {
+            "description": "Daily motion in degrees per day, negative when retrograde.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "name",
+          "longitude",
+          "latitude",
+          "distance",
+          "speed"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "transit_jd": {
+      "description": "Julian Day of the transit moment, echoed back.",
+      "type": "number"
+    },
+    "transit_natal_aspects": {
+      "items": {
+        "properties": {
+          "applying": {
+            "description": "True when the aspect is closing.",
+            "type": "boolean"
+          },
+          "aspect_angle": {
+            "description": "Exact angle of the aspect in degrees.",
+            "type": "number"
+          },
+          "aspect_type": {
+            "description": "Aspect name.",
+            "type": "string"
+          },
+          "natal_body": {
+            "description": "Natal graha aspected.",
+            "type": "string"
+          },
+          "natal_body_index": {
+            "description": "Index into natal_positions.",
+            "type": "integer"
+          },
+          "orb": {
+            "description": "Departure from exact, in degrees.",
+            "type": "number"
+          },
+          "transit_body": {
+            "description": "Transiting graha.",
+            "type": "string"
+          },
+          "transit_body_index": {
+            "description": "Index into transit_positions.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "transit_body",
+          "natal_body",
+          "aspect_type",
+          "orb"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "transit_positions": {
+      "description": "Positions at the transit moment.",
+      "items": {
+        "properties": {
+          "distance": {
+            "description": "Distance from the observer in AU.",
+            "type": "number"
+          },
+          "latitude": {
+            "description": "Ecliptic latitude in degrees.",
+            "type": "number"
+          },
+          "longitude": {
+            "description": "Longitude in degrees [0, 360), sidereal when an ayanamsha was applied.",
+            "type": "number"
+          },
+          "name": {
+            "description": "Body name.",
+            "type": "string"
+          },
+          "speed": {
+            "description": "Daily motion in degrees per day, negative when retrograde.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "name",
+          "longitude",
+          "latitude",
+          "distance",
+          "speed"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "natal_jd",
+    "transit_jd",
+    "natal_positions",
+    "transit_positions",
+    "transit_natal_aspects"
+  ],
+  "type": "object"
+}

Changedcompute_vargas4 fields changed

addedInput schema / properties / ayanamsha

Added value: +{
+  "description": "Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's ayanamsha_value output field reports the TRUE ayanamsha (mean plus nutation in longitude) already applied — nutation is included, do not add it yourself. Pass Tropical for no rotation. Systems: IndianOfficial = Indian Astronomical Ephemeris 2022, AYANAMSA section: 23 deg 51 min 25.53 sec at J2000.0, propagated by P03 general precession | FaganBradley = Fagan & Firebrace, Primer of Sidereal Astrology: synetic vernal point 335 deg 57 min 28.64 sec at B1950.0, ayanamsha = 360 deg minus SVP | Krishnamurti = Krishnamurti Padhdhati Vol-I: 22 deg 22 min 00 sec on the 1st of Chitra 1900, propagated at KSK's stated 50.2388475 arcsec/yr | Raman = Raman, A Manual of Hindu Astrology (1935), Ch. III Art. 49 | SuryaSiddhanta = Surya Siddhanta Ch. 3 vv. 9-12 | Yukteshwar = Yukteswar, The Holy Science (1894) | RevatiPaksha [star] = Revati at the sidereal initial point, the majority reading against Surya Siddhanta Ch. 8's own 359 deg 50 min, zeta Piscium per Hipparcos | PushyaPaksha [star] = Narasimha Rao, Introducing Pushya-paksha Ayanamsa | TrueChitra [star] = Self-describing condition; Spica per Hipparcos | ChandraHari [star] = Chandra Hari, Indian J. History of Science 33(4), 1998 | GalacticCenter0Sag [star] = Self-describing condition; Sgr A* per Gordon, de Witt & Jacobs (2023), AJ 165, 49.",
+  "enum": [
+    "IndianOfficial",
+    "FaganBradley",
+    "Krishnamurti",
+    "Raman",
+    "SuryaSiddhanta",
+    "Yukteshwar",
+    "RevatiPaksha",
+    "PushyaPaksha",
+    "TrueChitra",
+    "ChandraHari",
+    "GalacticCenter0Sag",
+    "Tropical"
+  ],
+  "type": "string"
+}

changedInput schema / properties / planet_longitude / description

Previous value: -"Sidereal longitude of the planet in degrees [0, 360) for direct varga computation"New value: +"Sidereal longitude of a single body in degrees [0, 360). When supplied, only this longitude is divided and no ephemeris is consulted; the result carries no graha name, dignity or bhava."

addedInput schema / properties / tradition

Added value: +{
+  "default": "modality",
+  "description": "Which Parashari reading to use where the texts diverge. 'modality' (default) starts the division from a movable/fixed/dual sign; 'element' starts it from a fire/earth/air/water sign. This changes D16, D20, D30 and D45 only; every other varga is identical under both. Source: BPHS Ch. 6; Phala Deepika Ch. 2.",
+  "enum": [
+    "modality",
+    "element"
+  ],
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "ayanamsha_value": {
+      "description": "True ayanamsha (mean plus nutation in longitude) applied before dividing, in degrees. Zero when Tropical.",
+      "type": "number"
+    },
+    "julian_day": {
+      "description": "The Julian Day the vargas were computed for, echoed back.",
+      "type": "number"
+    },
+    "tradition": {
+      "description": "The tradition actually used: 'modality' or 'element'.",
+      "type": "string"
+    },
+    "vargas": {
+      "description": "One entry per requested division, in the order requested.",
+      "items": {
+        "properties": {
+          "division": {
+            "description": "The division code as requested, e.g. D9.",
+            "type": "string"
+          },
+          "lagna_sign": {
+            "description": "Sign the ascendant occupies in this varga (0=Aries…11=Pisces). Absent when planet_longitude was supplied.",
+            "type": "integer"
+          },
+          "placements": {
+            "description": "One entry per graha, or a single entry for a supplied longitude.",
+            "items": {
+              "properties": {
+                "bhava": {
+                  "description": "Whole-sign house counted from the varga lagna, 1-12. Absent when planet_longitude was supplied.",
+                  "type": "integer"
+                },
+                "dignity": {
+                  "description": "Essential dignity in the varga sign. Absent for a supplied longitude, and for Rahu and Ketu, which have none.",
+                  "type": "string"
+                },
+                "planet": {
+                  "description": "Graha name. Absent for a supplied longitude.",
+                  "type": "string"
+                },
+                "rashi_longitude": {
+                  "description": "The sidereal longitude that was divided, in degrees [0, 360).",
+                  "type": "number"
+                },
+                "varga_sign": {
+                  "description": "Sign occupied within this varga (0=Aries…11=Pisces).",
+                  "type": "integer"
+                }
+              },
+              "required": [
+                "rashi_longitude",
+                "varga_sign"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "division",
+          "placements"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "julian_day",
+    "tradition",
+    "vargas"
+  ],
+  "type": "object"
+}

Changedsearch_muhurta1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "elevation_m": {
+      "description": "Elevation used, in metres.",
+      "type": "number"
+    },
+    "end_jd": {
+      "description": "End of the searched window, echoed back.",
+      "type": "number"
+    },
+    "latitude": {
+      "description": "Latitude used, in degrees.",
+      "type": "number"
+    },
+    "longitude": {
+      "description": "Longitude used, in degrees.",
+      "type": "number"
+    },
+    "min_quality": {
+      "description": "Quality floor the search applied.",
+      "type": "number"
+    },
+    "result_count": {
+      "description": "Number of entries in results.",
+      "type": "integer"
+    },
+    "results": {
+      "items": {
+        "properties": {
+          "factors": {
+            "items": {
+              "description": "Named factor contributing to the score.",
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "jd": {
+            "description": "Julian Day of the candidate moment.",
+            "type": "number"
+          },
+          "nakshatra": {
+            "description": "Nakshatra name.",
+            "type": "string"
+          },
+          "nakshatra_end_jd": {
+            "description": "Julian Day at which the nakshatra ends.",
+            "type": "number"
+          },
+          "quality_score": {
+            "description": "Composite score; higher is better.",
+            "type": "number"
+          },
+          "tithi_end_jd": {
+            "description": "Julian Day at which the tithi ends.",
+            "type": "number"
+          },
+          "tithi_name": {
+            "description": "Tithi name.",
+            "type": "string"
+          },
+          "tithi_number": {
+            "description": "Tithi number, 1-30.",
+            "type": "integer"
+          },
+          "weekday": {
+            "description": "Vara at that moment.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "jd",
+          "quality_score",
+          "weekday",
+          "tithi_name",
+          "nakshatra"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "start_jd": {
+      "description": "Start of the searched window, echoed back.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "start_jd",
+    "end_jd",
+    "result_count",
+    "results"
+  ],
+  "type": "object"
+}

Changedsearch_transits1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "end_jd": {
+      "description": "End of the searched window, echoed back.",
+      "type": "number"
+    },
+    "event_count": {
+      "description": "Number of entries in events.",
+      "type": "integer"
+    },
+    "events": {
+      "items": {
+        "properties": {
+          "applying": {
+            "description": "True when the aspect is closing at that moment.",
+            "type": "boolean"
+          },
+          "aspect_type": {
+            "description": "Aspect name.",
+            "type": "string"
+          },
+          "exact_jd": {
+            "description": "Julian Day at which the aspect is closest to exact.",
+            "type": "number"
+          },
+          "exact_orb": {
+            "description": "Orb at that moment, in degrees.",
+            "type": "number"
+          },
+          "natal_body": {
+            "description": "Natal point aspected.",
+            "type": "string"
+          },
+          "transiting_body": {
+            "description": "Transiting graha.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "transiting_body",
+          "natal_body",
+          "aspect_type",
+          "exact_jd"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "max_orb": {
+      "description": "Orb the search used, in degrees.",
+      "type": "number"
+    },
+    "start_jd": {
+      "description": "Start of the searched window, echoed back.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "start_jd",
+    "end_jd",
+    "event_count",
+    "events"
+  ],
+  "type": "object"
+}

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-10-24 19:30 across 17 tools

Disambiguation4/5

Most tools target clearly different computations (dasha, shadbala, panchanga, ashtakavarga, karakas), and descriptions explicitly disambiguate close pairs like compute_transit vs search_transits (positions vs exact aspect moments) and compute_drishti vs compute_synastry (intra-chart sign aspects vs inter-chart aspects). The only residual overlap is conceptual: compute_transit vs compute_gochara both concern transits, and compute_natal_chart vs compute_bhavas both involve houses, so an agent may briefly hesitate before selecting.

Naming Consistency5/5

All 17 names are snake_case with a clear verb_noun shape: 13 compute_* tools, 2 search_* tools, and emit_graph. The pattern is predictable and immediately readable, with no camelCase or stylistic mixing.

Tool Count4/5

17 tools is on the upper edge but each corresponds to a genuinely distinct Vedic computation (vargas, dasha, shadbala, combustion, ashtakavarga, gochara, panchanga, drishti, bhavas, synastry, composite, transits, muhurta, graph export). The surface is broad and no tool feels decorative, though it is slightly heavy for easy scanning.

Completeness4/5

The surface covers the full lifecycle from natal chart construction through derived analyses (vargas, karakas, dashas, shadbala, ashtakavarga), prediction (transits, gochara, muhurta), and export (emit_graph). Minor gaps remain: no explicit yoga/combination detection, and ashtakavarga explicitly omits Trikona/Ekadhipatya Shodhana and Pinda Sadhana, but agents can work around these.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Related MCP Connectors

VedaVisor Vedic Astrology MCP A
io.github.dchhill
Professional Vedic astrology tools for AI agents via MCP.
Entertainment & Media
3
https://mcp.vedavisor.com/mcp
AstroNest — Vedic Astrology & Ephemeris A
io.github.onedotlinks
Vedic astrology for AI agents: kundli, daśā, guna milan, life, venture and gem readings, ephemeris.
Entertainment & Media
211
https://www.astronest.ai/api/developer/mcp
IO Aerospace MCP Server C
org.io-aerospace
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
Aerospace & Astrodynamics Research & Data
214
https://mcp.io-aerospace.org
Vedic Astrology and Kundli MCP Server by RoxyAPI A
com.roxyapi
Vedic kundli, panchang, dashas, nakshatras and KP charts for AI agents, one API key.
Art & Culture
582
https://roxyapi.com/mcp/vedic-astrology

Related MCP Servers

VedAstro MCP Server
AI & Machine Learning Search
VedAstro
F
license
Not graded
quality
D
maintenance
World's first Vedic Astrology MCP Server — connect Claude, ChatGPT, Cursor, or any AI to real Vedic astrology. Provides horoscope predictions, compatibility matching, numerology, planetary positions, yogas and house analysis via MCP.
Updated 7 months ago (2026-03-25 22:21 UTC)
11
-
Precision astronomical
Research & Data Location Services
scottchronicity
A
license
Not graded
quality
C
maintenance
A self-contained MCP server that gives AI agents the ability to calculate high-precision astronomical data. It provides tropical zodiac coordinates, planetary speeds, retrograde detection, and house cusps using the trusted Swiss Ephemeris engine. 100%
Updated 7 months ago (2026-03-27 02:25 UTC)
4
AGPL 3.0
auseklis
Research & Data
igmizo
A
license
A
quality
C
maintenance
Astrology MCP server that computes natal charts, transits, synastry, progressions, returns, eclipses, retrogrades, and moon phases from a real ephemeris, enabling AI agents to provide accurate astrological calculations without hallucination.
Updated 4 months ago (2026-07-10 11:06 UTC)
12
99 npm
1
MIT
kundali-mcp
Research & Data
mrishabh7
F
license
Not graded
quality
D
maintenance
A Vedic astrology MCP server that computes birth charts, dashas, transits, and yogas locally using Swiss Ephemeris, enabling an LLM to interpret horoscopes and provide personalized advice.
Updated 4 months ago (2026-06-26 15:57 UTC)
-