Skip to main content
Glama

Vedaksha — Visión de los Vedas

Motor de efemérides y astrología védica en Rust de sala limpia, construido para la era de la IA agéntica. Precisión planetaria de sub-segundo de arco, cada algoritmo trazado a una fuente primaria, cualquier carta consultable como grafo de propiedades.

crates.io docs.rs PyPI npm CI MSRV License

Sitio web · Documentación · Playground · Referencia de API · Blog

clean-room · 0.103″ vs JPL Horizons · 1,069 tests + 24,350 oracle rows · MCP-native · BUSL-1.1 → Apache 2.0

Instalación · Inicio rápido · Precisión · Qué incluye · MCP + grafo de propiedades · Procedencia · Licencia


Instalación

Plataforma

Instalación

Notas

Rust

cargo add vedaksha

pipeline completo

Python

pip install vedaksha

motor vía WebAssembly, py3-none-any, Python ≥ 3.9 — sin cadena de herramientas de Rust

WASM

npm install vedaksha-wasm

navegador y edge, sin archivos de datos

MCP

cargo install vedaksha-mcp

stdio + HTTP (autenticación bearer)

Docker

docker run -e VEDAKSHA_MCP_TOKEN=… -p 3100:3100 ghcr.io/arthiqlabs/vedaksha-mcp

multi-arquitectura (amd64 + arm64)

Calcula janam kundali (cartas natales), panchanga, dashas, nakshatras, vargas, shadbala, ashtakavarga, muhurta y transits/gochara a partir de una efeméride de sub-segundo de arco (VSOP87A, ELP/MPP02, JPL DE440s/DE441).

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 · Δ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"]

Related MCP server: Precision astronomical ephemeris and planetary positions via the Swiss Ephemeris.

Inicio rápido

from vedaksha import Vedaksha

vk = Vedaksha()
chart = vk.natal_chart(julian_day=2451545.0, latitude=28.6139, longitude=77.2090)
cargo install vedaksha-mcp && vedaksha-mcp     # stdio: Claude Desktop, Cursor, VS Code

La ruta de Rust es un doctest compilado en crates/vedaksha/src/lib.rs.

Cada día juliano en las superficies públicas es UT1, no TT ni TDB. El motor convierte a TT internamente para los términos dinámicos y usa UT1 para la rotación de la Tierra, lo que fija el ascendente, el MC y las doce cúspides. Pasar un día juliano TDB añade una rotación de ΔT en lugar de eliminarla — 0,289° (17,3′) con el ΔT actual ≈ 69 s, en cada cúspide. La única excepción es la consulta SPK cruda (state_vector), que indexa el kernel directamente y toma TDB.

Precisión

Cada cifra se imprime mediante una prueba con nombre. Reproduce las tablas de efemérides con bash scripts/download_de440s.sh, luego cargo test -p vedaksha-ephem-core --release -- --include-ignored --nocapture; las cifras de ayanamsha provienen de cargo test -p vedaksha-astro sidereal, y la verificación cruzada contra una derivación independiente en Python de las mismas fuentes primarias de cargo test -p vedaksha-astro --test ayanamsha_fixture.

SpkReader vs JPL Horizons (DE441)oracle_comparison.rs, 24,350 filas confirmadas (10 cuerpos × 2,435 fechas, 1900–2100). Horizons sirve DE441, por lo que esto mide nuestro pipeline DE440s contra un kernel independiente.

Era

Comparaciones

Media

Máximo

1900–2025 (ΔT medido)

15,350

0.103″

1.187″ (Urano)

1900–2100 (todos)

24,350

0.878″

44.912″ (Luna, 2099)

15,349 de 15,350 comparaciones antes de 2026 son sub-segundo de arco. Más allá de 2025 el residual es predicción de ΔT, no error de efemérides: nuestra extrapolación de Espenak–Meeus y el ΔT de Horizons divergen en ~68 s en 2099, y el error escala con la tasa angular de un cuerpo — la Luna (0,64″/s) acumula ~45″, Plutón prácticamente nada. En 2099-02-06, cinco cuerpos que abarcan 0,03–0,64″/s implican todos el mismo desplazamiento de 66–71 s, lo que es la firma de una diferencia de reloj, no de un error de posición.

AnalyticalProvider vs JPL Horizonsanalytical_oracle.rs, 1900–2025: media general 0,239″, peor caso 1,896″ (Neptuno), Luna 0,169″ media vía ELP/MPP02. Muestreado densamente en 2,435 fechas por cuerpo.

Hasta el 2026-08-20 esas cifras eran 2,06″ de media y 24,22″ de peor caso, y este README atribuía la brecha a que VSOP87A es una teoría truncada. Eso era incorrecto, y la redacción protegía un defecto nuestro: el proveedor analítico respondía a EarthMoonBarycenter con la serie centrada en la Tierra de VSOP87A, por lo que el observador estaba a 4,671 km de distancia, y earth_state dividía una Luna relativa al baricentro por 1 + EMRAT en lugar de EMRAT para otros 56,8 km. Ambos están corregidos. El segundo también movió la ruta SPK, de 0,106″ a 0,103″.

ELP/MPP02 Moonlunar_horizons.rs: 0,015″ en J2000, 0,020–0,053″ entre 1500–2500 d.C.

Lo que no se mide

  • Las cúspides de las casas no se validan contra ninguna referencia externa.

  • Ningún ayanamsha se valida contra otra implementación, y eso es deliberado. Los once se derivan hacia adelante desde una fuente primaria — un capítulo, un comité, el propio artículo del proponente o un catálogo de estrellas — y cada uno reproduce su propio ancla a 1e-9° y, donde su fuente primaria documenta uno, su propio año cero. Lo que no se afirma es acuerdo con los números de nadie más: compararlos sería la ingeniería inversa que esta re-derivación existe para deshacer. Ver docs/audit/2026-08-17-ayanamsha-cleanroom/.

  • Las pruebas de dasha y nakshatra son pruebas invariantes, no comparaciones externas: verifican que las constantes de BPHS suman 120 años y que los límites teselan el círculo.

Qué incluye

Dos proveedores de efemérides. SpkReader lee JPL DE440s (~31 MB) para trabajo de sub-segundo de arco. AnalyticalProvider compila VSOP87A + ELP/MPP02 a constantes y no necesita archivos de datos — para WASM, edge y Cloudflare Workers.

Jyotish, desde fuentes primarias. 27 nakshatras con padas y señores · 5 sistemas de dasha (Vimshottari, Yogini, Ashtottari, y Chara y Narayana de Jaimini) · los 16 vargas (D-1 → D-60) · shadbala de seis componentes con Ishta/Kashta phala · 11 ayanamshas, cada uno trazable a un capítulo, una estrella o un comité · los cinco miembros del panchanga, con vara calculado desde el amanecer local y Rahu/Gulika Kalam como ventanas de tiempo reales · drishti graduado según BPHS cap. 26 · nodos medios, verdaderos y osculadores, todos referidos a la eclíptica de la fecha, con la variante J2000 que sigue el OM de DE441 a 0,6″ (listo para sub-señor KP).

Occidental: cálculo, no interpretación. 10 sistemas de casas, aspectos mayores con movimiento aplicativo/separativo, dignidades esenciales, sinastría y compuesto. ChartConfig por defecto es tropical. No hay capa interpretativa occidental ni paridad con la superficie Jyotish.

Crates, publicados en crates.io al unísono: vedaksha (paraguas, 7 locales) · -math · -ephem-core · -astro · -vedic · -graph · -mcp.

MCP + grafo de propiedades

17 herramientas, descubribles con un solo tools/list. El catálogo se genera a partir de las definiciones de Rust y se bloquea con una prueba de instantánea, por lo que no puede desviarse silenciosamente del código.

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

Cualquier carta se convierte en un grafo de propiedades mediante emit_graph o vedaksha_graph::chart_to_graph, emitiendo Cypher, SurrealQL, JSON-LD, JSON o texto de incrustación RAG. Un agente puede entonces preguntar "¿qué planetas aspectan al señor de la 7ª casa?" como una consulta de grafo en lugar de reimplementar la lógica de la carta. Los cálculos en sí devuelven structs tipados; el grafo es una proyección que se solicita.

Lo que una carta realmente produce: 4 de los 9 tipos de nodo de la ontología (Chart, Planet, Sign, House) y 7 de sus 12 tipos de arista. Nakshatra, Pada, Pattern, DashaPeriod y FixedStar están definidos en vedaksha_graph::ontology pero no se construyen a partir de un ComputedChart, que no lleva los datos que necesitan. Calcúlalos a través de sus propias APIs.

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

El modo HTTP requiere Authorization: Bearer <token> en cada POST y se niega a iniciar sin VEDAKSHA_MCP_TOKEN, a menos que pases --insecure-no-auth para una red de confianza. /health y el GET informativo permanecen abiertos.

Procedencia de sala limpia

Cada algoritmo implementado lleva un comentario de documentación // Source: que nombra su artículo o tratado primario — VSOP87A, ELP/MPP02, estándares IAU, BPHS, Jaimini. Dos subsistemas se han re-derivado de fuentes primarias detrás de un firewall documentado, y cada uno incluye su propio directorio de auditoría: la teoría lunar (2026-05-09) y la superficie sidérea (2026-08-17). Cada uno registra las fuentes primarias, el proceso, lo que se buscó y rechazó, y un generador que re-deriva los valores para que la afirmación pueda re-ejecutarse en lugar de tomarse por confianza. Ver también DATA_PROVENANCE.md. Esta es la evidencia que un licenciatario de BUSL-1.1 puede auditar.

En producción

Producto

Qué es

kundalimcp.com

MCP Jyotish de IA agéntica con la suite completa de cálculos. Se construye directamente sobre los crates vedaksha-*.

kundali.live

Endpoint de consumidor — lecturas basadas en chat e informes PDF de autoservicio.

Licencia

Business Source License 1.1 — SPDX BUSL-1.1, que es lo que muestran crates.io, PyPI y npm. (BSL-1.0 es la licencia Boost no relacionada, de ahí el prefijo BUSL.)

  • No comercial — gratis (personal, investigación, educación, herramientas internas).

  • Comercial — $500, cobrado una vez por organización. Productos y asientos ilimitados, perpetuo, y cubre la versión que licencias y todas las versiones posteriores — no se cobra de nuevo por versión. Comprar →

  • Se convierte a Apache 2.0 cuatro años después del lanzamiento de cada versión. Ese texto de licencia futura se mantiene en CHANGE-LICENSE.txt — es la Change License en términos BUSL, no una licencia que puedas elegir hoy.

Ver LICENSE, SECURITY.md, CONTRIBUTING.md y MAINTENANCE.md.


Copyright © 2026 ArthIQ Labs LLC · Licenciado bajo la Business Source License 1.1 (BUSL-1.1).

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sunYesSign index of Sun (0=Aries…11=Pisces)
marsYesSign index of Mars (0=Aries…11=Pisces)
moonYesSign index of Moon (0=Aries…11=Pisces)
lagnaYesSign index of Lagna (Ascendant)
venusYesSign index of Venus (0=Aries…11=Pisces)
saturnYesSign index of Saturn (0=Aries…11=Pisces)
jupiterYesSign index of Jupiter (0=Aries…11=Pisces)
mercuryYesSign index of Mercury (0=Aries…11=Pisces)

Output Schema

ParametersJSON Schema
NameRequiredDescription
tablesYesOne Bhinna Ashtakavarga per graha.
sarvashtakavargaYesTwelve 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
planetsNoOptional map of graha name to sidereal longitude, e.g. {"Mars": 200.4}. Each is placed into its bhava.
ascendantYesSidereal longitude of the ascendant [0, 360)

Output Schema

ParametersJSON Schema
NameRequiredDescription
housesYesTwelve entries in order.
planetsNoEmpty unless grahas were supplied.
lagna_signYesRashi 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sunYesSidereal longitude of Sun [0, 360). From compute_natal_chart's planets[] entry where name == "Sun", field longitude.
marsYesSidereal longitude of Mars [0, 360). From compute_natal_chart's planets[] entry where name == "Mars", field longitude.
moonYesSidereal longitude of Moon [0, 360). From compute_natal_chart's planets[] entry where name == "Moon", field longitude.
venusYesSidereal longitude of Venus [0, 360). From compute_natal_chart's planets[] entry where name == "Venus", field longitude.
saturnYesSidereal longitude of Saturn [0, 360). From compute_natal_chart's planets[] entry where name == "Saturn", field longitude.
jupiterYesSidereal longitude of Jupiter [0, 360). From compute_natal_chart's planets[] entry where name == "Jupiter", field longitude.
mercuryYesSidereal longitude of Mercury [0, 360). From compute_natal_chart's planets[] entry where name == "Mercury", field longitude.
mars_retrogradeNoTrue 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_retrogradeNoTrue 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_retrogradeNoTrue 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_retrogradeNoTrue 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_retrogradeNoTrue 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

ParametersJSON Schema
NameRequiredDescription
statesYesOne 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
chart_aYesMap 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_bYesMap of graha name to position for the second chart. Must have exactly the same graha names as chart_a.

Output Schema

ParametersJSON Schema
NameRequiredDescription
planetsYesOne 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 five 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). graha_signs takes the eight sign_index values compute_natal_chart already returns; Ketu is derived from Rahu and must not be supplied. Returns a JSON dasha tree with start/end Julian Days.

ParametersJSON Schema
NameRequiredDescriptionDefault
levelsNoNumber of nested dasha levels (1–5). Ignored by Chara and Narayana.
systemNoDasha system selectorVimshottari
birth_jdYesBirth 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_signNoLagna (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.
graha_signsNoNatal 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.
moon_longitudeNoNatal Moon sidereal longitude in degrees [0, 360). Required for Vimshottari, Ashtottari, Yogini.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already provide readOnlyHint=true, and the description goes beyond that with substantial behavioral detail: it returns a JSON dasha tree with start/end Julian Days, clarifies that the epoch is UT1 and never converted, explains Ketu is derived from Rahu, and documents a historical indexing mismatch. No contradictions 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.

Conciseness4/5

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

The description is long but dense with necessary information for a tool with two distinct parameter families and five dasha systems. It front-loads the purpose and then organizes requirements by system. A few points are repeated from the schema, but there is 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 tool's complexity — multiple systems, conditional parameters, nested objects, and a shared convention with compute_natal_chart — the description is complete. It covers prerequisites, parameter sourcing, output shape, time-scale behavior, and edge-case conventions. The presence of an output schema also reduces the burden of explaining return structure.

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 baseline is 3, but the description adds meaningful semantics: it ties each parameter to specific dasha systems, explains the sign-to-lord period counting rule for Chara and Narayana, and warns that Ketu must not be supplied. Some detail is duplicated from the schema, but the added cross-system relationships still earn credit.

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 dasha (planetary period) sequences') and immediately enumerates the five supported systems. It differentiates the tool from generic astrology tools by explaining that it handles multiple dasha systems with distinct input requirements.

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 explicit input-requirement conditions: Yogini needs moon_longitude; Chara and Narayana need both lagna_sign and graha_signs. It also tells the agent where to source these values (compute_natal_chart's sign_index). It does not explicitly contrast with sibling tools, but for this tool's own selection logic the guidance is strong.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sunYesSidereal longitude of Sun [0, 360)
ketuYesSidereal longitude of Ketu [0, 360)
marsYesSidereal longitude of Mars [0, 360)
moonYesSidereal longitude of Moon [0, 360)
rahuYesSidereal longitude of Rahu [0, 360)
venusYesSidereal longitude of Venus [0, 360)
saturnYesSidereal longitude of Saturn [0, 360)
jupiterYesSidereal longitude of Jupiter [0, 360)
mercuryYesSidereal longitude of Mercury [0, 360)

Output Schema

ParametersJSON Schema
NameRequiredDescription
aspectsYes

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sunYesTransit sign index of Sun (0=Aries … 11=Pisces)
marsYesTransit sign index of Mars
moonYesTransit sign index of Moon
venusYesTransit sign index of Venus
saturnYesTransit sign index of Saturn
schoolNoExemption profile applied to the raw vedha candidate listGeometry
jupiterYesTransit sign index of Jupiter
mercuryYesTransit sign index of Mercury
vedha_tableNoVedha pair table sourceBphs29
natal_reference_signYesSign index of the natal reference point — natal Moon for Chandra Gochara, natal Lagna for Lagna-based Gochara

Output Schema

ParametersJSON Schema
NameRequiredDescription
entriesYes

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sunYesSidereal longitude of Sun [0, 360)
marsYesSidereal longitude of Mars [0, 360)
moonYesSidereal longitude of Moon [0, 360)
rahuNoSidereal longitude of Rahu [0, 360). Required for scheme '8'.
venusYesSidereal longitude of Venus [0, 360)
saturnYesSidereal longitude of Saturn [0, 360)
schemeNoKaraka scheme: '7' (default, Sun–Saturn) or '8' (adds Rahu + Pitrikaraka)7
jupiterYesSidereal longitude of Jupiter [0, 360)
mercuryYesSidereal longitude of Mercury [0, 360)

Output Schema

ParametersJSON Schema
NameRequiredDescription
karakasYesOne 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 a ChartGraph in JSON format containing planetary positions, house cusps, aspects, nakshatras, and dignities.

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYesGeographic latitude in degrees [-90, +90]
ayanamshaNoSidereal 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
longitudeYesGeographic longitude in degrees [-180, +180], east positive
julian_dayYesJulian 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_systemNoHouse system: Placidus, Koch, Equal, WholeSign, etc.Placidus

Output Schema

ParametersJSON Schema
NameRequiredDescription
housesYes
aspectsYes
planetsYesOne entry per computed body.
julian_dayYesThe Julian Day the chart was cast for, echoed back.
config_summaryNoOne-line record of the ephemeris, house system and ayanamsha used.
true_ayanamsha_valueNoTrue ayanamsha (mean plus nutation in longitude) applied, in degrees. Zero for a tropical chart.

TDQS

A3.8/5.0
Behavior3/5

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

The description confirms this is a read-only computation that returns a JSON ChartGraph, which complements the readOnlyHint annotation. It does not discuss edge cases, precision limits, or failure modes, but with annotations already covering side effects, the added return-type context is adequate but not exceptional.

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 two short, front-loaded sentences with no filler. The action is stated first, and the return-value summary earns its place without duplicating the schema.

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 combination of a rich input schema, an available output schema, and the readOnlyHint means the agent has enough structure to select and invoke the tool correctly. The description states purpose and output, while the schema handles detailed inputs and return shape. A brief routing note against sibling compute_* tools would improve completeness but is not essential.

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?

All five parameters are thoroughly described in the input schema, including the important UT1-vs-TT warning for julian_day and detailed ayanamsha system definitions. At 100% schema description coverage, the baseline of 3 is appropriate, and the prose description's 'time and location' phrasing adds no new parameter-level meaning.

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 opens with a specific verb, 'Compute', and names the exact resource, 'natal astrological chart', along with the required time and location context. It also summarizes the returned ChartGraph contents, which clarifies the tool's scope. It does not explicitly contrast the tool with siblings like compute_transit or compute_bhavas, so it stops short of a top score.

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 phrase 'for a given time and location' states a clear usage context: use this tool when a natal chart is needed for specific inputs. It does not list exclusions or direct the agent to alternatives such as compute_transit or compute_bhavas, but the context is explicit enough to guide basic selection.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
jdYesJulian 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.
sunYesSidereal longitude of Sun [0, 360)
moonYesSidereal longitude of Moon [0, 360)
latitudeYesObserver latitude in degrees. Required — the vara is reckoned from local sunrise, so it depends on the observer.
longitudeYesObserver longitude in degrees, east positive. Required.
elevation_mNoObserver 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_minutesNoOffset 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

ParametersJSON Schema
NameRequiredDescription
varaYes
yogaYes
tithiYes
karanaYes
nakshatraYes

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 six-fold Shadbala (Sthana, Dig, Kala, Cheshta, Naisargika, Drik Bala) per planet, with the Sthana sub-components (uccha, ojhayugma, kendradi, drekkana) and ishta/kashta phala, per BPHS Ch.27-28. Sthana Bala omits Saptavargaja Bala and Kala Bala covers Nathonnatha and Paksha only.

ParametersJSON Schema
NameRequiredDescriptionDefault
planetsYesArray of planet data objects.
is_daytimeNoTrue if the birth moment falls between sunrise and sunset. Feeds Nathonnatha Bala within Kala Bala.
moon_phase_waxingNoTrue during shukla paksha (waxing Moon). Feeds Paksha Bala within Kala Bala.

Output Schema

ParametersJSON Schema
NameRequiredDescription
planetsYesOne entry per graha supplied, in input order.

TDQS

A4.5/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: which sub-components are included, which are deliberately omitted, and the limited scope of Kala Bala. This prevents the agent from assuming a full traditional Shadbala calculation and adds real decision-relevant information.

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, front-loaded sentences convey the full scope, inclusions, and exclusions without redundancies. Every clause earns its place, and the most important identifier ('six-fold Shadbala') appears first.

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 rich input schema, readOnly annotation, and presence of an output schema, the description is complete enough for an agent to invoke the tool correctly. It explicitly calls out the calculation source and the specific omissions that would otherwise be surprises.

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 already provides 100% coverage with per-parameter descriptions explaining which Bala each field drives. The description adds domain-level context about components, but it does not add meaningful new parameter semantics beyond what the schema documents, so baseline 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 uses a specific verb ('Compute') and resource ('six-fold Shadbala'), enumerates all six components, and identifies the source (BPHS Ch.27-28). This clearly distinguishes it from siblings like compute_drishti or compute_ashtakavarga by naming a distinct astrological computation.

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 about what the computation covers and its explicit limitations, such as Sthana Bala omitting Saptavargaja and Kala Bala covering Nathonnatha and Paksha only. It does not explicitly name alternative sibling tools or state when not to use this tool, but the scope is clear enough for an agent to route a Shadbala request here.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
chart_aYesMap of graha name to sidereal longitude [0, 360) for the first chart, e.g. {"Sun": 10.0, "Moon": 130.0}.
chart_bYesMap of graha name to sidereal longitude [0, 360) for the second chart. Need not use the same names as chart_a.
aspect_setNo'major' (default) tests the five Ptolemaic aspects; 'all' adds semi-sextile, semi-square, quintile, sesquiquadrate, bi-quintile and quincunx.major
orb_factorNoMultiplier 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

ParametersJSON Schema
NameRequiredDescription
aspectsYes

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
natal_jdYesJulian Day of the natal chart in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms.
natal_latYesNatal geographic latitude in degrees [-90, +90]
natal_lonYesNatal geographic longitude in degrees [-180, +180], east positive
transit_jdYesJulian 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

ParametersJSON Schema
NameRequiredDescription
natal_jdYesJulian Day of the natal chart, echoed back.
transit_jdYesJulian Day of the transit moment, echoed back.
natal_positionsYesNatal positions used for the comparison.
transit_positionsYesPositions at the transit moment.
transit_natal_aspectsYes

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYesGeographic latitude in degrees [-90, +90]
ayanamshaNoSidereal 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.
divisionsYesVarga division codes to compute, e.g. ["D1", "D9", "D10"]
longitudeYesGeographic longitude in degrees [-180, +180], east positive
traditionNoWhich 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_dayYesJulian 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_longitudeNoSidereal 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

ParametersJSON Schema
NameRequiredDescription
vargasYesOne entry per requested division, in the order requested.
traditionYesThe tradition actually used: 'modality' or 'element'.
julian_dayYesThe Julian Day the vargas were computed for, echoed back.
true_ayanamsha_valueNoTrue 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatYesTarget output format
latitudeNoObserver 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.
longitudeNoObserver longitude, degrees east. Required when chart_json is a computed chart.
chart_jsonYesEither 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})
classificationNoOptional 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) — the per-candidate vara and tithi/nakshatra refinement make this tool far more expensive per day of range than a transit search, so a wider span would make a single call take minutes.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_jdYesEnd 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.
latitudeYesGeographic latitude in degrees [-90, +90]
start_jdYesStart 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.
longitudeYesGeographic longitude in degrees [-180, +180], east positive
elevation_mNoObserver 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_qualityNoMinimum quality score [0.0, 1.0] for muhurta inclusion (default 0.5)
tz_offset_minutesNoOffset 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

ParametersJSON Schema
NameRequiredDescription
end_jdYesEnd of the searched window, echoed back.
resultsYes
latitudeNoLatitude used, in degrees.
start_jdYesStart of the searched window, echoed back.
longitudeNoLongitude used, in degrees.
elevation_mNoElevation used, in metres.
min_qualityNoQuality floor the search applied.
result_countYesNumber of entries in results.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses significant behavioral traits: the computational cost and why the range is capped, the internal refinement steps (per-candidate vara and tithi/nakshatra refinement), and the existence of a specific error code (MUHURTA_SEARCH_RANGE_TOO_LARGE). It also mentions time-scale consistency (UT1 vs TT) and cross-tool consistency expectations (elevation value matching compute_panchanga) in the schema. This is rich behavioral context that helps agents anticipate performance and failure modes.

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

Conciseness5/5

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

Two sentences with no wasted words. The first sentence front-loads purpose and output; the second delivers the critical constraint and cost warning. Every part earns its place, and the error code reference is compact.

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 7-parameter tool with a full output schema and read-only annotations, the description covers the essential usage context: what it searches, what it returns, and the key operational constraint (30-day cap, cost). The schema covers parameter details. It falls slightly short of 5 because it never explicitly positions the tool against siblings like search_transits or compute_panchanga beyond the generic 'transit search' cost comparison, and an agent might still be unsure about selection criteria among these similar astronomical tools.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining why the start_jd/end_jd span is capped at 30 days and the cost implications of the per-candidate refinement. This rationale is genuinely useful for parameter understanding and invocation, lifting the score above baseline. However, individual parameter meanings are almost entirely left to the schema, which is already thorough.

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 ('Search') and resource ('auspicious time windows (muhurta)') with explicit context: within a period for a geographic location. It also lists what the tool returns (ranked candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions). It further distinguishes itself from 'a transit search' by cost, which both identifies the sibling category and clarifies its unique role.

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 to use the tool (searching muhurta windows) and provides a strong cost-based constraint: the 30-day cap and the warning that wider spans make calls take minutes. It implicitly differentiates from the sibling search_transits by calling out the per-day expense relative to a transit search, but it does not explicitly say 'use this for muhurta, use search_transits for transit positions' or name alternatives such as compute_panchanga.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodiesNoTransiting bodies to include. Defaults to all planets.
end_jdYesEnd of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB.
aspectsNoAspect types to filter (e.g. conjunction, opposition, trine). Defaults to major aspects.
max_orbNoMaximum orb in degrees (default 1.0)
start_jdYesStart 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_positionsYesArray of natal planet positions to check transits against

Output Schema

ParametersJSON Schema
NameRequiredDescription
end_jdYesEnd of the searched window, echoed back.
eventsYes
max_orbNoOrb the search used, in degrees.
start_jdYesStart of the searched window, echoed back.
event_countYesNumber 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.

  1. 1 tool updatev9.1.2
    • 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."
  2. 4 tool updatesv8.0.1
    • 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"
        +}
  3. 16 tool updatesv8.0.0
    • 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"
        +}
  4. 17 tool updatesv7.0.0
    • First observedcompute_ashtakavarga
    • First observedcompute_bhavas
    • First observedcompute_combustion
    • First observedcompute_composite
    • First observedcompute_dasha
    • First observedcompute_drishti
    • First observedcompute_gochara
    • First observedcompute_karakas
    • First observedcompute_natal_chart
    • First observedcompute_panchanga
    • First observedcompute_shadbala
    • First observedcompute_synastry
    • First observedcompute_transit
    • First observedcompute_vargas
    • First observedemit_graph
    • First observedsearch_muhurta
    • First observedsearch_transits

TDQS

A4.2/5.0

Scored across 17 tools

Disambiguation5/5

Each tool addresses a distinct astrological calculation or search (natal chart, dashas, karakas, combustion, shadbala, vargas, transits, transit aspects, muhurta, ashtakavarga, gochara, panchanga, drishti, bhavas, synastry, composite, graph export). Even closely related tools like compute_transit, search_transits, and compute_gochara have clearly separated purposes described in their descriptions.

Naming Consistency4/5

Tool names predominantly follow a compute_verb_noun pattern, with search_ for search operations and emit_graph for output. While the verbs vary by action category, the snake_case verb_noun format is consistent and semantically predictable, though not a single uniform verb pattern across all tools.

Tool Count4/5

With 17 tools, the set is slightly above the typical 3-15 range, but each tool provides a distinct Vedic astrology computation or search, and the breadth is justified for a comprehensive server covering natal, transit, electional, and relationship domains. It is not excessive or redundant.

Completeness4/5

The tool surface covers major Vedic astrology workflows: natal chart computation, multiple dasha systems, vargas, transits, muhurta, panchanga, aspects, houses, ashtakavarga, shadbala, gochara, synastry, composite, and graph export. Minor gaps remain (e.g., advanced Tajika or detailed compatibility matching), but core calculations and derivations are well supported.

Maintenance

ActivityNo data
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • 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.
    9
    -
  • 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%
    4
    AGPL 3.0
  • A
    license
    A
    quality
    B
    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.
    12
    41 npm
    1
    MIT
  • 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.
    -