Three years ago, I watched a senior Jyotishi identify a problem with our matchmaking platform in under a minute. We had built the feature carefully. The charts rendered correctly. The compatibility scores looked reasonable. He looked at one recommended pair and said, in the specific quiet way that means someone is being polite about something serious: "Their Rajju does not match."
The pair scored 28 out of 36 under standard Ashtakoot calculation, a strong result. But Rajju dosha, per classical South Indian matchmaking tradition, is not a score modifier. It is a hard veto. When two prospective matches share a Nakshatra group that creates Rajju conflict, the Guna Milan score becomes irrelevant. Our API returned a number. It did not check the veto. We had not known to ask for it.
That experience started a longer investigation into what astrology APIs actually need to return versus what they typically do. This post is about one specific finding: why AI products that use a language model for astrology calculation are broken at the infrastructure level, and what an astrology MCP server does to fix it.
Why LLMs Cannot Compute Charts
When a language model produces a birth chart, it is not calculating. It is generating text that matches the pattern of birth chart output it saw during training. The distinction sounds pedantic until you look at what it means in practice.
Planetary positions are precise. Jupiter at the moment of a specific birth is at a specific longitude to three decimal places, in a specific Nakshatra, on a specific Pada, in a specific house by Rashi and a potentially different house by Bhava Chalit. Whether Saturn is combust depends on its exact orb from the Sun at that instant. Whether a Neecha Bhanga Raja Yoga fires depends on whether the dispositor of the debilitated planet occupies a Kendra. None of this can be approximated. The calculation either uses a real ephemeris, NASA JPL DE431 is the standard, or it does not.
A language model has no ephemeris. It has compressed statistical patterns from text that discussed astrology. Those patterns produce plausible-looking output. They do not produce correct output. The gap between the two is not a rounding error. It is the difference between a calculated fact and a confident guess.
What MCP Actually Is
Model Context Protocol is an open standard from Anthropic that lets AI agents call external tools at runtime. Instead of generating an answer from training weights, the agent calls a tool, receives structured data, and uses that data to compose its response. The tool does the work. The agent does the communication.
This is architecturally significant. It means a language model connected to an astrology MCP server is not guessing at Jupiter's position. It is querying an ephemeris engine, receiving the computed result, and narrating that result. The model's job becomes interpretation and communication, which it is genuinely good at. The calculation happens elsewhere, by software built specifically for it.
An astrology MCP server exposes the calculation layer as callable tools. Natal chart, Vimshottari Dasha tree, Panchanga for a given date and location, compatibility with Rajju and Vedha checked as hard vetoes, classical yoga detection with BPHS citations. When Claude or any other MCP-compatible agent needs this data, it calls the tool. It does not generate the data. It receives it.
What This Changes for Developers
The practical consequence is that two categories of astrology product now exist. Products where the AI both computes and interprets, meaning all calculation is approximated by the model. And products where a real engine computes and the AI interprets, meaning calculation is exact and the model's role is precisely scoped.
The first category has a failure mode that is invisible to most users. The charts look correct. The language is fluent. The Dasha dates sound plausible. But the positions are generated, not calculated. For casual horoscope content this may not matter. For matchmaking, Muhurta selection, or any application where a family or practitioner will review the output, it matters completely.
The second category requires a real ephemeris API behind the MCP server. The server validates nothing itself. It queries the calculation engine, structures the response, and hands it to the agent. The computation is correct because the engine is built for computation, not for generating text that resembles computation.
The Rajju Problem Specifically
Rajju is a good example because it illustrates a category of calculation that is not about numerical precision at all. It is about classification. Each Nakshatra belongs to one of five Rajju groups. Two people whose birth Nakshatras fall in the same Rajju group create a conflict that classical Parashari texts treat as a prohibitive dosha, regardless of how high their Guna Milan score is.
A language model producing matchmaking output may include Rajju in its response if the training data mentioned it. But it will not reliably check it correctly against the actual birth Nakshatras, because checking it requires knowing the exact Nakshatra for each chart, which requires computing the Moon's precise sidereal longitude, which requires an ephemeris. The model is generating text about Rajju, not evaluating it.
This is what the Jyotishi saw in forty-five seconds. Not that the software had a bug. That the software had no mechanism for this check at all.
Every AI astrology product that does not call a real ephemeris API is producing approximate data dressed as precise calculation. The interface is real. The underlying numbers are generated.
The Jyotishi identified the problem in forty-five seconds because the problem was structural, not numerical. The software returned a score. It had no mechanism for the classification check that classical texts treat as prior to the score. An MCP server connected to a real ephemeris engine does not solve that problem automatically. It creates the conditions under which the problem can be solved, because the calculation is now real and the structure of the response can now carry the veto alongside the score. That is the infrastructure distinction that matters.
The next post in this series goes one level deeper: why the specific calculations that matter most in Jyotish are precisely the ones that break when approximated, and how the Asterwise engine handles the edge cases that most implementations skip.