What is the minimum I need to pass to compute a chart with Vedika?

A datetime in ISO 8601, latitude, longitude, and a timezone (an IANA name or UTC offset). On the V2 computation endpoints these are flat fields; on the natural-language query endpoint they live under a birthDetails object. Getting the timezone right matters most: an incorrect or omitted offset shifts the ascendant and can move planets across sign boundaries.

How does the MCP server help an AI assistant use astrology data?

The Model Context Protocol server (npx @vedika-io/mcp-server) exposes 36 tools that an MCP-compatible client can call directly, such as computing a chart, resolving a place to coordinates, or running a divisional-chart breakdown. Instead of you wiring HTTP requests, the assistant discovers the tools, calls them with structured arguments, and receives structured results it can ground its reply on.

Grounding an LLM on real astrology computations

Q: How do I keep interpretations attributable to real classical sources?

Separate computation from interpretation. Compute placements deterministically, then constrain the interpretation layer to cite classical texts actually used in Jyotish, KP, and Western training such as Brihat Parashara Hora Shastra, Phaladeepika, Saravali, and Ptolemy's Tetrabiblos. Never let the model invent verse numbers or statistics. Vedika's interpretive responses are built around these sources rather than free-form generation.

Q: Can I verify the computations are precise?

Yes. The underlying XALEN Ephemeris is open source under Apache-2.0 (crates.io/xalen, PyPI xalen, npm @xalen/wasm) with roughly 2,200 tests, validated against JPL DE440 and swetest with no chart deviating beyond 0.1 degrees across a five-million-chart test set. That is astronomical precision for planetary positions; it is independent of how you choose to interpret those positions.

To ground an LLM on real astrology, you stop asking the model to compute anything. You compute the chart deterministically with an ephemeris-backed API, hand the verified placements to the model as structured facts, and let it do the one thing it is good at: explaining them in natural language. This deep-dive walks through that pattern with the Vedika API, which exposes 700+ operations across 25 domains (704 enumerated as of June 2026) and ships a public MCP server so AI assistants can call the tools directly.

Why an LLM cannot be trusted to compute placements

A language model predicts text. It has no ephemeris, no sidereal-vs-tropical switch, and no notion that a one-hour timezone error can push the Moon into the next sign. Ask it for an ascendant and it returns something that looks like an answer, assembled from the statistical shadow of astrology content it was trained on. Sometimes it is right. You cannot tell when it is wrong, and neither can your user.

The failure is structural, not a prompt-engineering problem. Planetary positions come from integrating orbital mechanics for an exact instant and location. That is arithmetic an ephemeris performs and a token predictor approximates. The grounding pattern fixes this by drawing a hard line: computation is deterministic, interpretation is generative, and the model only ever sees facts it did not invent.

The two layers you must separate

Computation layer — sidereal and tropical positions, house cusps, divisional charts, dashas, aspects, yogas. Deterministic. Reproducible. Verifiable against an ephemeris.
Interpretation layer — what a placement means, phrased for a human. Generative, but constrained to cite real classical sources rather than free-associate.

Conflating these is the root cause of hallucinated astrology. Keep them apart and the model can no longer get a Saturn placement wrong, because it never computes one.

Step 1: Compute the chart deterministically

Vedika's V2 computation endpoints take flat birth parameters and return code-computed placements. Latitude, longitude, datetime, and timezone are the whole contract. Getting the timezone right is the single highest-leverage detail: an omitted or wrong offset shifts the ascendant and can move planets across sign boundaries.

curl -X POST https://api.vedika.io/v2/astrology/chart \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "datetime": "1990-08-15T14:30:00",
    "latitude": 19.0760,
    "longitude": 72.8777,
    "timezone": "Asia/Kolkata",
    "system": "vedic"
  }'

The same birth data can be evaluated under three systems in one API: Vedic (sidereal), Western (tropical), and KP, with Jaimini, Tajaka, Lal Kitab, and numerology available alongside. Switching system to western returns tropical positions for the identical instant, which matters because a chart that is Leo sidereal can read as Virgo tropical for the same birth. You never want a model guessing which convention applies.

Precision you can audit

The positions come from the XALEN Ephemeris, Vedika's own open-source engine (Apache-2.0; crates.io/xalen, PyPI xalen, npm @xalen/wasm, roughly 2,200 tests). It is validated against JPL DE440 and swetest, with no chart deviating beyond 0.1 degrees across a five-million-chart test set. That figure is astronomical precision for planetary positions, and it is the floor your grounding sits on. It says nothing about whether an interpretation is meaningful; it guarantees the inputs to that interpretation are correct.

Step 2: Hand the facts to the model

Once you hold verified placements, the prompt construction is mechanical. You inject the computed chart as structured context and instruct the model to interpret only what it is given. Use a generic LLM client here; any function-calling model works.

import requests

BASE = "https://api.vedika.io"
HEADERS = {"x-api-key": "vk_live_your_key_here"}

def compute_chart(birth):
    r = requests.post(f"{BASE}/v2/astrology/chart", headers=HEADERS, json=birth)
    r.raise_for_status()
    return r.json()

def build_grounded_prompt(chart, question):
    facts = "\n".join(
        f"- {p['name']}: {p['sign']} {p['degree']:.2f} (house {p['house']})"
        for p in chart["planets"]
    )
    return (
        "You are an astrology assistant. Use ONLY the computed placements below.\n"
        "Do not invent positions, degrees, or houses. If a fact is absent, say so.\n\n"
        f"Computed chart:\n{facts}\n\nQuestion: {question}"
    )

chart = compute_chart({
    "datetime": "1990-08-15T14:30:00",
    "latitude": 19.0760, "longitude": 72.8777,
    "timezone": "Asia/Kolkata", "system": "vedic",
})
prompt = build_grounded_prompt(chart, "What does my Moon placement suggest about temperament?")
# pass `prompt` to your function-calling model as the user/system context

The instruction "use only the computed placements" is doing real work. With the facts present and the rule explicit, the model interprets rather than fabricates. The degrees, signs, and houses are no longer its responsibility.

Step 3: Let Vedika AI do interpretation too

If you would rather not run your own interpretation layer, the natural-language endpoint folds computation and grounded interpretation into one call. You send a question plus birthDetails, and Vedika AI computes the chart server-side before answering, so the reply is already grounded.

curl -X POST https://api.vedika.io/api/v1/astrology/query \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "What does my Moon placement say about my temperament?",
    "birthDetails": {
      "datetime": "1990-08-15T14:30:00",
      "latitude": 19.0760,
      "longitude": 72.8777,
      "timezone": "Asia/Kolkata"
    },
    "speed": "fast"
  }'

For chat-style UIs, stream the same request through /api/v1/astrology/query/stream over Server-Sent Events to render tokens as they arrive. The speed: "fast" flag routes to Vedika Swift for lower latency; omit it for the deeper Vedika Pro Ultra path. Either way the placements underneath are the deterministic ones, and the interpretation is constrained to cite real classical sources.

Step 4: Wire it into an AI assistant via MCP

The cleanest integration for agentic clients skips HTTP plumbing entirely. Vedika ships a public Model Context Protocol server that exposes 36 tools to any MCP-compatible client or IDE.

npx @vedika-io/mcp-server

Once registered, the assistant discovers tools such as chart computation, place-to-coordinate resolution, and divisional-chart breakdowns. When a user asks about their birth chart, the agent calls the compute tool, receives structured placements, and grounds its reply on the returned facts. The model never types a degree value of its own; it asks the tool. That is the same separation as the manual pattern, enforced by the protocol instead of by your prompt.

Keeping interpretations honest

Grounding the math is half the job. The other half is making sure interpretation stays attributable. An astrological claim such as "Saturn in the seventh house delays partnership" should trace to a classical text actually taught in Jyotish, KP, or Western certification, not to a paraphrase of blog content. Vedika constrains its interpretive layer to sources like Brihat Parashara Hora Shastra, Phaladeepika, Saravali, Jataka Parijata, the Jaimini Sutras, the KP Readers, and Ptolemy's Tetrabiblos. If you run your own interpretation layer, apply the same discipline: never let the model invent verse numbers, percentages, or accuracy statistics. A wrong citation is worse than no citation.

Key facts

Grounding rule: computation is deterministic; interpretation is generative. The model never computes a placement.
Compute endpoint: POST /v2/astrology/* with flat datetime, latitude, longitude, timezone.
Grounded NL endpoint: POST /api/v1/astrology/query (question + birthDetails); SSE variant at /query/stream.
Auth: x-api-key: vk_live_*; base URL https://api.vedika.io.
Coverage: 700+ operations across 25 domains; Vedic, Western, and KP in one API; 30 languages (14 Indic).
Precision: XALEN Ephemeris (Apache-2.0), validated vs JPL DE440 and swetest, no chart beyond 0.1 degrees across a five-million-chart test.
Agent integration: public MCP server npx @vedika-io/mcp-server with 36 tools.

How it compares

Other astrology APIs cover the basics well. Prokerala (from around $19/mo) has broad endpoint coverage and a long-standing developer base; AstrologyAPI.com (around $29/mo) ships solid Vedic data; RoxyAPI (around $39/mo) offers clean computation endpoints. If all you need is raw chart math, any of them can serve you. Vedika's differentiators are specific to the grounding problem: three systems behind one schema, an open-source ephemeris you can audit yourself, a grounded natural-language layer that ties interpretations to classical sources, and a public MCP server so AI assistants can call the tools without custom integration. You can compare plans on the pricing page and read the full reference in the docs.

Try it without a key

The fastest way to validate this pattern is the free sandbox, which mirrors the production shapes with no authentication. Compute a chart, inspect the placements, and feed them to your model before you write a line of billed code. When you are ready, a vk_live_* key turns the same requests live at $0.01–$0.05 per query. For more on the streaming path, see streaming astrology responses over SSE.

FAQ

Why can't I just ask an LLM to compute a birth chart directly?

Language models pattern-match text; they do not run an ephemeris. Ask for a Moon sign and you may get a plausible but wrong answer because the model never integrated the planet's position for the exact datetime, location, and timezone. Compute the chart deterministically and pass the verified placements in, so the model interprets facts instead of inventing them.

What is the minimum I need to pass to compute a chart?

A datetime in ISO 8601, latitude, longitude, and a timezone. On the V2 endpoints these are flat fields; on the natural-language endpoint they live under birthDetails. The timezone matters most, since a wrong offset shifts the ascendant and can move planets across sign boundaries.

How does the MCP server help an AI assistant?

It exposes 36 tools an MCP-compatible client can call directly, such as computing a chart or resolving a place to coordinates. The assistant discovers the tools, calls them with structured arguments, and grounds its reply on structured results instead of guessing.

How do I keep interpretations attributable?

Separate computation from interpretation and constrain the interpretation layer to real classical texts used in formal training, such as Brihat Parashara Hora Shastra, Phaladeepika, and Ptolemy's Tetrabiblos. Never let the model invent verse numbers or statistics.