Skip to main content
Glama

Vedaksha — 来自吠陀的洞见

为智能体AI时代打造的洁净室 Rust 星历表与吠陀占星引擎。 亚角秒级行星精度,每个算法都可追溯到主要来源,任何星盘都可作为属性图查询。

crates.io docs.rs PyPI npm CI MSRV License

网站 · 文档 · 游乐场 · API 参考 · 博客

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

安装 · 快速开始 · 精度 · 内含内容 · MCP + 属性图 · 来源 · 许可证


安装

平台

安装

备注

Rust

cargo add vedaksha

完整流水线

Python

pip install vedaksha

通过 WebAssembly 引擎,py3-none-any,Python ≥ 3.9 — 无需 Rust 工具链

WASM

npm install vedaksha-wasm

浏览器与边缘,无数据文件

MCP

cargo install vedaksha-mcp

stdio + HTTP(bearer 认证)

Docker

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

多架构(amd64 + arm64)

从亚角秒级星历表(VSOP87A、ELP/MPP02、JPL DE440s/DE441)计算 janam kundali(本命盘)、panchangadashasnakshatrasvargasshadbalaashtakavargamuhurtatransits/gochara

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.

快速开始

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

Rust 路径是 crates/vedaksha/src/lib.rs 中的编译 doctest。

公共接口上的每个儒略日都是 UT1,既不是 TT 也不是 TDB。引擎在内部转换为 TT 以用于动力学项,并使用 UT1 进行地球自转,这修正了上升点、天顶和所有十二个宫位。传入 TDB 儒略日会加上 ΔT 的旋转量而不是减去——以今天的 ΔT ≈ 69 秒计算,每个宫位会偏差 0.289°(17.3′)。唯一的例外是原始 SPK 查询(state_vector),它直接索引内核并接受 TDB。

精度

每个数字都由一个命名测试打印。使用 bash scripts/download_de440s.sh 重现星历表,然后运行 cargo test -p vedaksha-ephem-core --release -- --include-ignored --nocapture;岁差数字来自 cargo test -p vedaksha-astro sidereal,与相同主要来源的独立 Python 推导的交叉验证来自 cargo test -p vedaksha-astro --test ayanamsha_fixture

SpkReader 对比 JPL Horizons(DE441)oracle_comparison.rs,24,350 行已提交数据(10 个天体 × 2,435 个日期,1900–2100 年)。Horizons 提供 DE441,因此这衡量了我们的 DE440s 流水线与独立内核的对比。

时期

比较次数

平均值

最大值

1900–2025(ΔT 已测量)

15,350

0.103″

1.187″(天王星)

1900–2100(全部)

24,350

0.878″

44.912″(月球,2099)

2026 年之前的 15,350 次比较中有 15,349 次低于角秒。2025 年之后的残差是 ΔT 预测问题,而非星历表误差: 我们的 Espenak–Meeus 外推与 Horizons 的 ΔT 在 2099 年相差约 68 秒,误差随天体的角速度缩放——月球(0.64″/s)产生约 45″,冥王星几乎没有。在 2099-02-06,五个角速度在 0.03–0.64″/s 之间的天体都暗示相同的 66–71 秒偏移,这是时钟差异的特征,而非位置误差。

AnalyticalProvider 对比 JPL Horizonsanalytical_oracle.rs,1900–2025 年:总体平均值 0.239″,最坏情况 1.896″(海王星),月球通过 ELP/MPP02 平均 0.169″。每个天体在 2,435 个日期上密集采样。

直到 2026-08-20,这些数字是平均值 2.06″ 和最坏情况 24.22″,本 README 将差距归因于 VSOP87A 是截断理论。那是错误的,措辞掩盖了我们自己的缺陷:分析提供者用 VSOP87A 的地心级数回答 EarthMoonBarycenter,导致观测者偏离 4,671 公里,而 earth_state 将质心相对月球除以 1 + EMRAT 而不是 EMRAT,又偏差 56.8 公里。两者都已修复。第二个问题也影响了 SPK 路径,从 0.106″ 变为 0.103″。

ELP/MPP02 月球lunar_horizons.rsJ2000 处 0.015″,1500–2500 年间为 0.020–0.053″。

未测量的内容

  • 宫位宫头未与任何外部参考进行验证。

  • 没有一种岁差系统与其他实现进行验证,这是有意为之。 所有十一种都是从主要来源向前推导的——章节、委员会、提案者的论文或星表——每种都将其锚点重现到 1e-9°,并在其主要来源记录的情况下重现其零年。声称与任何其他人的数字一致:与它们比较将违背此重新推导旨在消除的逆向工程。参见 docs/audit/2026-08-17-ayanamsha-cleanroom/

  • Dasha 和 nakshatra 测试是不变性测试,而非外部比较:它们验证 BPHS 常数之和为 120 年,并且边界平铺整个圆周。

内含内容

两个星历表提供者。 SpkReader 读取 JPL DE440s(约 31 MB)用于亚角秒级工作。AnalyticalProvider 将 VSOP87A + ELP/MPP02 编译为常量,无需数据文件——适用于 WASM、边缘和 Cloudflare Workers。

Jyotish,源自主要来源。 27 个 nakshatras,包含 padas 和主星 · 5 种 dasha 系统(Vimshottari、Yogini、Ashtottari 以及 Jaimini 的 Chara 和 Narayana)· 全部 16 个 vargas(D-1 → D-60)· 六部分 shadbala 及 Ishta/Kashta phala · 11 种 ayanamshas,每种都可追溯到章节、恒星或委员会 · panchanga 的五个分支,vara 从当地日出计算,Rahu/Gulika Kalam 作为真实时间窗口 · 根据 BPHS 第 26 章的分级 drishti · 平均、真和密切节点,均参考当日黄道,J2000 变体跟踪 DE441 的 OM 至 0.6″(KP 副主星就绪)。

西方:计算而非解释。 10 种宫位系统、主要相位及入相位/离相位运动、本质尊贵、合盘和组合盘。ChartConfig 默认热带黄道。没有西方解释层,也不与 Jyotish 表面保持一致。

Crates,同步发布到 crates.io:vedaksha(伞形,7 种语言)· -math · -ephem-core · -astro · -vedic · -graph · -mcp

MCP + 属性图

17 个工具,可通过单个 tools/list 发现。目录从 Rust 定义生成,并由快照测试锁定,因此不会与代码静默漂移。

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

任何星盘都可以通过 emit_graphvedaksha_graph::chart_to_graph 转换为属性图,输出 Cypher、SurrealQL、JSON-LD、JSON 或 RAG 嵌入文本。然后代理可以询问“哪些行星相位第七宫主星?”作为图查询,而不是重新实现星盘逻辑。计算本身返回类型化结构体;图是您请求的投影。

星盘实际产生的内容: 本体论 9 种节点类型中的 4 种(ChartPlanetSignHouse)和 12 种边类型中的 7 种。NakshatraPadaPatternDashaPeriodFixedStarvedaksha_graph::ontology 中定义,但不从 ComputedChart 构建,因为后者不包含它们所需的数据。通过各自的 API 计算这些。

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

HTTP 模式要求每个 POST 都带有 Authorization: Bearer <token>,并且如果没有 VEDAKSHA_MCP_TOKEN 则拒绝启动,除非您传递 --insecure-no-auth 用于受信任网络。/health 和信息性 GET 保持开放。

洁净室来源

每个实现的算法都带有 // Source: 文档注释,命名其主要论文或论文——VSOP87A、ELP/MPP02、IAU 标准、BPHS、Jaimini。两个子系统已从主要来源在文档化的防火墙后重新推导,每个都附带自己的审计目录:月球理论(2026-05-09)和恒星黄道表面(2026-08-17)。每个都记录了主要来源、过程、搜索和拒绝的内容,以及一个重新推导值的生成器,以便可以重新运行声明而不是信任。另请参阅 DATA_PROVENANCE.md。这是 BUSL-1.1 被许可人可以审计的证据。

生产环境

产品

描述

kundalimcp.com

智能体 AI Jyotish MCP,包含完整计算套件。直接构建在 vedaksha-* crates 之上。

kundali.live

消费者端点——基于聊天的阅读和自助 PDF 报告。

许可证

Business Source License 1.1 — SPDX BUSL-1.1,这是 crates.io、PyPI 和 npm 显示的许可证。(BSL-1.0 是不相关的 Boost 许可证,因此使用 BUSL 前缀。)

  • 非商业用途 — 免费(个人、研究、教育、内部工具)。

  • 商业用途 — 500 美元,每个组织一次性收费。无限产品和席位,永久有效,涵盖您许可的版本及其后发布的每个版本——不会按版本再次收费。购买 →

  • 每个版本发布四年后转换为 Apache 2.0。该未来许可证文本保存在 CHANGE-LICENSE.txt 中——这是 BUSL 术语中的 Change License不是您今天可以选择的许可证。

参见 LICENSESECURITY.mdCONTRIBUTING.mdMAINTENANCE.md


版权所有 © 2026 ArthIQ Labs LLC · 根据 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.
    -