Six decisions, longer form.

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. Vedākṣha'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 BSL-1.1 library, 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 fully-packaged production-ready MCP — full Vedic computation suite with narrative generation, multi-school, multilingual — there's KundaliMCP, built on Vedākṣha core 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"}'

Most Vedic computation in the wild is layered on top of Western tropical engines from the 1990s, with nakshatras, dashas, and vargas bolted on via wrappers maintained by third parties. Correctness depends on whoever wrote the wrapper and whether they read the primary source or copied another library.

Vedākṣha starts from the classical texts directly. The DashaSystem enum has exactly five variants because BPHS Ch.46–47 and the Jaimini Sutras define exactly five systems we chose to implement. Every variant traces back to a named chapter and verse. The same discipline runs through nakshatras, vargas, yogas, 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
// Sources: 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
}

Legacy ephemeris engines return floating-point arrays. Turning those into something queryable — “does Mars aspect Saturn”, “which planets are in mutual reception” — requires building a translation layer in application code, and that layer needs to be rebuilt for every new query shape.

Vedākṣha's output is a ChartGraphwith 10 typed node types (Chart, Planet, Sign, House, Nakshatra, Pada, Pattern, DashaPeriod, Yoga, FixedStar) and 13 typed edge types (PlacedIn, Occupies, Aspects, Rules, Disposits, CuspOf, BelongsTo, PartOfPattern, InNakshatra, ConjunctStar, DashaLord, ContainsPeriod, HasYoga). Graph pattern queries like “find all planets aspecting the 7th lord” become one traversal instead of application code.

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-emit · 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)-[:InNakshatra]->(:Nakshatra {name:"U.Bhadrapada"})

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

Legacy ephemeris libraries are written in C for 1990s desktop applications. Running them in a browser, a serverless function, or a Docker container requires FFI bindings, build system patches, and platform-specific CI steps. Keeping those bindings correct across runtime targets is ongoing maintenance.

Vedākṣha is pure Rust. The same codebase compiles natively for Linux, macOS, and Windows; to WebAssembly (zero bundled data files) for browser and edge runtimes; and to a Python extension via PyO3 with type stubs. There is no C dependency to manage.

The WASM target's zero-data-file constraint means the bundle carries the full ephemeris computation in the Wasm binary itself — no fetch at runtime, no CORS issues, no CDN dependency.

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

Vedākṣha'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. The engine's type system does not provide a slot for personal data.

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.

Most Vedic computation software derives its algorithms from other software rather than from primary published sources. This creates a chain of implementation copies where errors are invisible — correctness is “consistent with the tool we validated against,” not “verified against an independent reference.”

Vedākṣha 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. Analytical planetary positions (VSOP87A, ELP/MPP02) are validated against JPL Horizons DE441 — a separate, independently maintained reference. The osculating lunar node achieves <0.03° against JPL across the 1900–2100 range.

The test suite runs 870 unit tests plus 8,700 oracle rows on every CI push, on both Ubuntu and macOS. No platform-specific numeric behavior can hide. Claimed accuracy figures appear in the table on the home page; every figure in that table has a corresponding test or oracle row backing it.