Updated 2026-08-20, checked against the live endpoint. KundaliMCP has consolidated its surface to nine product-level tools: kundali, lifemap, kundali_milan, shubh_muhurat, panchang, pramaan, chat, submit_feedback, get_version. Single-school Parashari (BPHS) interpretation, seven languages, a 409-yoga catalog. It embeds Vedaksha 6.0.1, so it does not necessarily track the engine version this site reports. The previous version of this note said 17 tools, which is Vedaksha's engine-primitive count and was never the product's: the two are different facts. The launch narrative below is otherwise unchanged.
When we shipped Vedaksha v2.0.0, the question that kept coming up was: who actually uses an astronomical library? The honest answer was: nobody yet. That was the whole point of writing one. A clean-room ephemeris is most useful when something gets built on top of it.
That something is KundaliMCP, an agentic-AI-native Vedic astrology platform. It launched this week. Both Vedaksha and KundaliMCP are built and operated by ArthIQ Labs, so this is a maintainer-built reference deployment rather than a third-party endorsement. We are eating our own astrological dog food, which we think is the right way to prove a library is real.
What KundaliMCP is
KundaliMCP is a Jyotish toolkit exposed over the Model Context Protocol. An AI agent points at the server and gets a small set of composed tools: cast a chart, qualify yogas, forecast dasha periods and events, search auspicious windows, query divisional charts, check compatibility, recommend remedies, generate localized narratives, and emit graph representations for downstream RAG pipelines.
Interpretation follows the Parashari (BPHS) tradition. Output is offered in seven languages (English, Hindi, Sanskrit (Devanagari), Tamil, Telugu, Kannada, and Bengali), picked up directly from the Vedaksha locale crate.
Notably, KundaliMCP stores zero personally-identifiable information. Birth data goes in, computed charts come out, and nothing in between is persisted. This works because Vedaksha is a stateless library: every chart is a pure function of (julian day, latitude, longitude, configuration). The product layer can be PII-blind because the engine layer never had a session to begin with.
What we kept from the library
Every astronomical computation in KundaliMCP comes straight from Vedaksha, unchanged. The AnalyticalProvider with VSOP87A planetary series and ELP/MPP02 lunar theory runs in production untouched. The same ayanamsha implementations are exposed to end users: whatever the engine ships, the product ships. The same osculating-node calculation that agrees with JPL DE441 to within 0.6 arcseconds places Rahu and Ketu in every chart the product returns.
When a customer reports a position that disagrees with another tool by a few arcseconds, we trace it to a specific ayanamsha definition or precession model, the same way we always have, because the library is the same. No reimplementation in the product layer. No quiet drift between "what the docs say" and "what production runs."
What the product layer added
Vedaksha exposes 17 MCP tools out of the box: the engine primitives. KundaliMCP layers product-level compositions on top. None of these belong in the engine; all of them are short compositions over Vedaksha primitives:
None of these belong in the library: they encode product opinions. All of them are short compositions of Vedaksha primitives. That ratio (thin product layer over a complete library) is what the architecture was designed for.
What we learned about MCP-first product surfaces
The most surprising part of building an MCP-first product was how much falls out for free when the library already speaks the protocol. Vedaksha's MCP server implementation handles JSON-RPC 2.0, schema generation, validation, and error semantics. KundaliMCP inherits all of it, then layers product-specific tools on top using the same tool-definition pattern. There is no REST adapter. There is no GraphQL schema to maintain. The protocol is the API.
The trade-off is that the audience is narrower, for now. MCP-aware AI agents can use KundaliMCP today; legacy clients need a thin REST shim. We've decided the agent surface is the future-default and any non-MCP clients can adapt, rather than the other way around.
What this means for Vedaksha
A library with one production user is not a thriving ecosystem, and we are not pretending otherwise. What KundaliMCP proves is narrower and more useful: the engine carries a full product without modification. Performance, accuracy, type ergonomics, locale coverage, MCP semantics, all production-tested under real query load now.
That makes Vedaksha less of an academic exercise. If you are considering building an astrology product, an AI-agent assistant, or a research tool that touches planetary positions, the engine you would use is the same one running at kundalimcp.com right now. We will keep it that way.
Try it: kundalimcp.com · Build on it: cargo add vedaksha · Read the docs: /docs