Vedic astrology computation from primary sources

Most APIs are documented in markdown and discovered by humans reading docs. An MCP surface is documented in JSON Schema and discovered by agents at runtime, without a human in the loop. Vedaksha's canonical introspection mirror at https://vedaksha.net/api/mcp answers initialize, ping, tools/list, get_version, and tools/call over JSON-RPC 2.0.

The tool schemas are not maintained separately. They are generated directly from the Rust ToolDefinition structs in crates/vedaksha-mcp/src/tools/. A drift-guard test (snapshot_matches_current_tool_definitions) fails CI if the published JSON snapshot diverges from what the current Rust source would produce.

The mirror is unauthenticated for introspection (tools/listreturns the full catalog without a key). tools/callreturns a -32001 JSON-RPC error with self-host instructions. Vedaksha is a BUSL-1.1 engine, so the tools run where you host them: cargo install vedaksha-mcp, pip install vedaksha, npm i vedaksha-wasm, or build from source. For a hosted MCP server built on the engine, there is KundaliMCP, built on the Vedaksha engine by the same team at ArthIQ Labs.

curl https://vedaksha.net/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Vedaksha starts from the classical texts directly. The DashaSystem enum has eight variants: Vimshottari, Ashtottari, Yogini, Chara and Narayana from BPHS Ch.46–47 and the Jaimini Sutras, and Sthira, Niryana Shoola and Maheshwara, which v10.0.0 adds on a shared Jaimini strength. The same discipline runs through nakshatras, vargas, drishti, shadbala, ashtakavarga, and gochara.

When a Vedic concept is ambiguous between commentators, for example, the number of chara karakas (7 or 8 depending on the school), we model both schemes in the type system and let the caller select. We do not pick a winner silently.

// crates/vedaksha-mcp/src/tools/compute_dasha.rs
// First five: BPHS Ch.46–47, Jaimini Sutras
pub enum DashaSystem {
    Vimshottari,   // 120-yr · 9 lords · moon
    Ashtottari,    // 108-yr · 8 lords · moon
    Yogini,        // 36-yr · 8 yoginis · moon
    Chara,         // Jaimini · lagna-based
    Narayana,      // Jaimini · lagna-based
    Sthira,        // added v10.0.0 · Jaimini strength
    NiryanaShoola, // added v10.0.0 · Jaimini strength
    Maheshwara,    // added v10.0.0 · Jaimini strength
}

Chart computation returns structured chart data. Its graph projection is a ChartGraph. The ontology defines 9 typed node types (Chart, Planet, Sign, House, Nakshatra, Pada, Pattern, DashaPeriod, FixedStar) and 12 typed edge types (PlacedIn, Occupies, Aspects, Rules, Disposits, CuspOf, BelongsTo, PartOfPattern, InNakshatra, ConjunctStar, DashaLord, ContainsPeriod). Graph pattern queries like “find all planets aspecting the 7th lord” become one traversal instead of application code.

A computed chart yields fewer types than the ontology defines. chart_to_graph builds 4 of those node types (Chart, Planet, Sign, House) and 7 of those edge types (PlacedIn, Occupies, Aspects, Rules, Disposits, CuspOf, BelongsTo). The other five node types and five edge types are defined in vedaksha_graph::ontology but are not built from a ComputedChart, which does not carry the data they need. Compute those through their own APIs.

Deterministic node IDs mean re-emitting the same chart is idempotent. Multi-chart queries (synastry, transit overlay, RAG over a chart corpus) become graph patterns instead of bespoke loops.

// vedaksha-graph · CypherEmitter
MERGE (c:Chart {id:"chart_2024_03_20"})
MERGE (sun:Planet {name:"Sun"})
MERGE (sun)-[:PlacedIn]->(:Sign {name:"Pisces"})
MERGE (sun)-[:Occupies]->(:House {number:4})
MERGE (sun)-[:BelongsTo]->(c)

MATCH (m:Planet {name:'Mars'})
   -[:Aspects]->(s:Planet {name:'Saturn'})
RETURN m, s

Vedaksha is pure Rust. The same codebase compiles natively for Linux, macOS, and Windows, and to WebAssembly (zero bundled data files) for browser and edge runtimes. There is no C dependency to manage.

The Python package (pip install vedaksha) ships the real Rust engine compiled to WebAssembly and runs it via wasmtime. The bindings use the same Rust engine. Bit-level reproducibility depends on the computation and target architecture. One py3-none-any wheel covers every OS and CPU wasmtime supports, on any Python ≥ 3.9, with no Rust toolchain and no per-platform builds. It exposes a typed library, a CLI, a self-hostable MCP server (stdio + HTTP), and an optional FastAPI REST projection, on both the analytical and sub-arcsecond (DE440s) ephemeris tiers.

The WASM target's zero-data-file constraint means the bundle carries the full ephemeris computation in the Wasm binary itself, so it fetches nothing at runtime and depends on no CDN. The Docker image of the MCP server ships for linux/amd64 and linux/arm64.

Birth data (date, time and location) is sensitive under GDPR, DPDP and similar frameworks. The risks are in retention, access and linkage, not in the computation. An engine that accepts a name alongside astronomical coordinates makes the name the application's problem to scrub before the engine even touches it.

Vedaksha's MCP input schema requires only julian_day, latitude, and longitude. There is no name field, no birth_date field in human-readable form, no user_id. The caller converts date + time to a Julian Day before calling the engine. These inputs can still relate to a person; omitting a name does not establish anonymity.

Every ChartGraph output carries a DataClassification tag: Anonymous, Pseudonymized, or Identified. The default at construction is Anonymous. Upgrading to Identified is an explicit caller decision, never the default. Downstream systems can inspect this tag to enforce retention and access policy without parsing chart content.

Vedaksha is a clean-room implementation. Every module that implements a cited algorithm carries a // Source: doc-comment pointing at the specific paper, edition, and section. The committed fixture contains 24,350 reference rows. The headline measurements use 15,350 SPK comparisons and 13,815 analytical comparisons over 1900-2025. SpkReader agrees to 0.096″ mean (0.272″ max, 15,350 comparisons) and the data-file-free AnalyticalProvider to 0.160″ mean (1.473″ max, Neptune, 13,815 comparisons).

The test suite runs 1603 tests (unit, integration and doctests) on every CI push, and the 24,350-row oracle comparison runs in the scheduled Full Validation job. Both run on Linux; macOS is exercised at release time, when the Darwin binary is built and tested. Claimed accuracy figures appear in the table on /accuracy; each measured figure there traces to the JPL validation runs described above.