Vedic Astrology MCP Server

What MCP is, in one paragraph

The Model Context Protocol is an open standard for letting a language model call external tools. Instead of pasting astrological data into a prompt, you point the model's client at a server; the client asks the server what tools it has, the server answers with names, descriptions and JSON Schemas, and from then on the model can call any of them mid- conversation and reason over what comes back. This server publishes the Jagannatha Hora Vedic astrology engine that way. It is read-only — every tool computes and returns; none of them write, send, charge or change anything — so an agent can call them freely without a confirmation step in front of each one.

How to connect

In a client that supports remote MCP servers, adding the endpoint URL is the entire setup. There is no package to install and no process to spawn — this is not a stdio server.

Which clients this works with

MCP clients that support remote HTTP servers

Work directly. Add the endpoint URL as a remote or custom MCP server. Because the server requires no authentication, leave any API-key or OAuth field empty — and note that a client which insists on OAuth for remote servers will not connect.

Clients that only speak stdio

Need a bridge. A stdio-to-HTTP proxy (the mcp-remote npm package is the common one) runs locally as the stdio server and forwards to this URL. Configure the proxy, not this endpoint, as the command.

Your own agent code

Nothing special required. It is HTTP and JSON — an MCP SDK's HTTP transport works, and so does a plain POST, as the examples below show.

Client support for remote MCP servers moves quickly and differs between products and versions, so the honest answer is the one above: this server is a standard HTTP JSON-RPC MCP endpoint with no authentication, and it works with any client that can talk to one. If yours only speaks stdio, put a stdio-to-HTTP bridge in front of it.

Verify it in two commands

curl -sS -X POST "https://jagannatha-hora-359167915530.europe-west1.run.app/mcp" \
  -H "content-type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"ping"}'

{"jsonrpc":"2.0","id":1,"result":{}}

curl -sS -X POST "https://jagannatha-hora-359167915530.europe-west1.run.app/mcp" \
  -H "content-type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Machine-readable versions of this page

Same facts, in formats a program would rather have.

• horoscopes.today/mcp-tools.json — The tool manifest: every tool name, title, description and input schema as JSON. Useful for planning a call before you connect.
• horoscopes.today/mcp.md — This whole reference as plain Markdown, for LLM fetchers.
• horoscopes.today/openapi.json — OpenAPI 3.1 for the REST surface, if you would rather call HTTP endpoints directly.
• horoscopes.today/api.md — The REST reference in Markdown.

Protocol

Standard JSON-RPC 2.0. These are the methods the server implements; anything else returns a -32601.

initialize

Handshake. Returns protocolVersion, capabilities ({"tools": {"listChanged": false}}) and serverInfo. The server echoes back the protocolVersion the client sent, or 2024-11-05 when the client sends none.

tools/list

Every tool with its title, description, JSON Schema and annotations. Call it when you connect and use the schemas it returns.

tools/call

Runs one tool. Takes name and arguments. The result carries the output twice: as content, a single text part whose text is the JSON-encoded result, and as structuredContent, the same result as a JSON object.

ping

Returns an empty result. Use it to check the server is up.

notifications/*

Accepted, with no response body, per JSON-RPC notification semantics.

Transport detail

• The transport is JSON-RPC 2.0 over HTTP. POST each request to the endpoint and the JSON-RPC response comes straight back in the body — no session, no handshake beyond initialize.
• It is not a stdio server: there is no command to spawn and no package to install.

Errors

-32700

Parse error. The request body was not valid JSON.

-32601

Method not found. A method outside the list above.

-32602

Invalid params. tools/call with no name or an unknown tool name; birth details that fail to parse (a missing required field names the fields it is missing); a birth place inside the polar circles (beyond about 66.5° north or south); or a date on which the Sun does not rise or set at the place. get_marriage_match is the exception: its input problems come back as a normal result with an error field.

-32603

Internal error. The calculation failed. The message carries the reason.

The shared inputs

Most tools identify a chart the same way, with the same 7 fields. They are listed once here; the tool tables below only name what each tool adds on top.

Three tools take no birth details at all: list_divisional_charts takes no parameters whatsoever, get_planet_ingress works on planets and dates alone, and get_marriage_match takes two nested person objects instead.

Event location override

get_gochara, get_gochara_range and get_muhurta also accept an event location, for the common case where someone was born in one place and is asking about something happening in another. Every field is optional and falls back to the corresponding birth value.

All 33 tools

Grouped by what they are for. Tools that take parameters beyond the birth block have those parameters tabulated in the next section.

What a tool call returns

A tools/call result carries the output twice: as content, a single text part whose text is the JSON-encoded result, and as structuredContent, the same result as a JSON object. 32 of the 33 tools wrap their result in the same envelope — {"section": "...", "data": ...} — with some adding one field, such as the varga that was applied. generate_horoscope is the exception and returns its overview at the top level.

{
  "jsonrpc": "2.0", "id": 4,
  "result": {
    "content": [
      { "type": "text",
        "text": "{\"section\": \"chara_karakas\", \"data\": { ... }}" }
    ],
    "structuredContent": { "section": "chara_karakas", "data": { ... } }
  }
}

Tool parameters

The 8 tools below take something beyond the shared birth block. Defaults are applied by the server at call time — no tool schema declares a JSON-Schema default, so a client reading the schema will not see them.

The 55 dasha systems

get_dasha accepts any of these as its system argument. 28 are graha (planetary) systems, where the periods belong to planets:

vimsottari, ashtottari, yogini, shodasottari, dwadasottari, panchottari, satabdika, chaturaaseeti_sama, shashtisama, shattrimsa_sama, dwisatpathi, kaala, buddhi_gathi, naisargika, aayu, tara, karaka, tithi_ashtottari, tithi_yogini, karana_chaturaaseeti_sama, saptharishi_nakshathra, rasi_bhukthi_vimsottari, yoga_vimsottari, ashtaka_varga_planet, ashtaka_varga_sign, ashtaka_varga_pinda, moola_graha, rashmi

The other 27 are rasi (sign) systems, where the periods belong to signs. These naturally run shallower, which is why the default depth is 2 rather than 3:

narayana, chara, kendraadhi_rasi, sudasa, drig, nirayana, shoola, kendraadhi_karaka, lagnamsaka, padhanadhamsa, mandooka, sthira, tara_lagna, brahma, varnada, yogardha, navamsa, paryaaya, trikona, kalachakra, chakra, sandhya_panchaka, chathurvidha_utthara, karaka_kendraadhi, lagna_kendraadhi, niryaana, raashiyanka

A worked example: an agent answering a real question

Take the question "I was born on 27 July 1993 at 1:51pm in Hassan, India. Which dasha am I running, and is Saturn giving me trouble right now?" An agent with this server connected answers it in three calls. Nothing below is hypothetical — it is the literal JSON-RPC each step sends, and the results are real, abridged.

Step 1 — establish the chart

The agent calls generate_horoscope first. This is the expensive step; later calls for the same birth details reuse the computed chart and come back quickly.

POST https://jagannatha-hora-359167915530.europe-west1.run.app/mcp
content-type: application/json

{
  "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": {
    "name": "generate_horoscope",
    "arguments": {
      "date": "1993-07-27", "time": "13:51:00", "place": "Hassan",
      "latitude": 13.0, "longitude": 76.1, "timezone": 5.5
    }
  }
}

{
  "birth_details": {
    "date": "1993-07-27",
    "time": "13:51:00",
    "place": "Hassan",
    "latitude": 13.0,
    "longitude": 76.1,
    "timezone": 5.5,
    "ayanamsa_mode": "LAHIRI"
  },
  "summary": {
    "ascendant_nakshatra": "Vishakha",
    "ascendant_pada": 4,
    "moon_nakshatra": "Vishakha",
    "moon_pada": 2,
    "moon_nakshatra_lord": "Jupiter",
    "sun_nakshatra": "Pushya",
    "ascendant_sign": "Scorpio",
    "moon_sign": "Libra",
    "sun_sign": "Cancer"
  },
  "rasi_chart": {
    "Ascendant": {
      "sign": "Scorpio",
      "degree": 0.46,
      "house": 1,
      "nakshatra": "Vishakha",
      "pada": 4
    },
    "Moon": {
      "sign": "Libra",
      "degree": 26.09,
      "house": 1,
      "nakshatra": "Vishakha",
      "pada": 2,
      "retrograde": false
    }
    /* …the other eight */
  },
  "calendar_info": { /* … */ },
  "available_sections": [
    "amsa_rulers",
    "arudha_padhas",
    "ashtakavarga",
    "ayanamsa_value",
    "bhava_bala",
    "bhava_chart"
    /* …27 more */
  ]
}

Step 2 — the running dasha

Now the timing question. The agent asks for Vimshottari to three levels, and the server marks which maha, antar and pratyantar contain the as_of_date, so the model does not have to do date arithmetic over a period tree. as_of_date defaults to today; it is fixed here so the example can be reproduced.

{
  "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": {
    "name": "get_dasha",
    "arguments": {
      "date": "1993-07-27", "time": "13:51:00",
      "latitude": 13.0, "longitude": 76.1, "timezone": 5.5,
      "system": "vimsottari", "depth": 3, "as_of_date": "2026-10-03"
    }
  }
}

{
  "section": "dasha",
  "data": {
    "dasha_type": "graha",
    "system": "vimsottari",
    "as_of": "2026-10-03",
    "depth": 3,
    "levels_available": 3,
    "maha_timeline": [
      {
        "level": "maha",
        "ruler": "Jupiter",
        "start": "1986-04-03",
        "end": "2002-04-03",
        "relation": "past"
      }
      /* … */
    ],
    "current_maha": {
      "level": "maha",
      "ruler": "Mercury",
      "start": "2021-04-03",
      "end": "2038-04-03",
      "relation": "current",
      "antars": [/* …nine antars */]
    },
    "current_antar": {
      "level": "antar",
      "ruler": "Venus",
      "start": "2024-08-27",
      "end": "2027-06-28",
      "relation": "current",
      "parent_maha": "Mercury",
      "pratyantars": [/* …nine pratyantars */]
    },
    "current": {
      "maha": "Mercury",
      "antar": "Venus",
      "pratyantar": "Saturn",
      "path": "Mercury > Venus > Saturn",
      "current_period_ends": "2026-12-03"
    }
  }
}

Step 3 — the Saturn question

"Is Saturn giving me trouble" is a Sade Sati question, so the agent calls the tool that answers it directly rather than trying to infer it from planetary positions.

{
  "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": {
    "name": "get_saturn_transit",
    "arguments": {
      "date": "1993-07-27", "time": "13:51:00",
      "latitude": 13.0, "longitude": 76.1, "timezone": 5.5
    }
  }
}

Three calls, and the model now has the running period with its end date and the Saturn transit windows — the two things the question actually turned on. It writes the answer from computed data instead of from whatever it remembered about Vedic astrology.

The shape of this matters more than the specifics. Do not reach for generate_horoscope and then ask the model to find the answer in it — that is the megabyte-into-the-context-window mistake. Establish the chart, then call the one or two tools that own the question. Each returns kilobytes.

How the server behaves

Every tool is read-only

Each tool advertises readOnlyHint: true, destructiveHint: false, idempotentHint: true and openWorldHint: false. Nothing here writes, sends, charges or changes anything. An agent can call any of them without a confirmation step.

Compute the chart once, then slice it

Computing a chart is the expensive step. Follow-up calls for the same birth details reuse the computed chart and come back quickly, so the intended pattern is one generate_horoscope followed by as many section tools as the question needs — not one call that drags a multi-megabyte chart back to the model.

No authentication

There is no API key to obtain and no OAuth flow to complete — which also means an MCP client that requires OAuth for remote servers will not connect. Do not send anything you would not put in a public request.

Rate limit

30 requests a minute per client IP address. Every JSON-RPC request counts, initialize and tools/list included, not only tool calls. Over the limit, the HTTP response is 429 with the body {"error": "Rate limit exceeded: 30 per 1 minute"}.

Results change only when the engine does

The same arguments give the same result, with two exceptions: get_dasha centres on today's date unless you send as_of_date, and results change when the calculation engine is updated. The REST API's engine_revision field (on /horoscope and /marriage-match) tells you when that happens.

Send only the advertised parameters

Use the parameters each tool's schema lists. If you need a non-default ayanamsa, a different house system or other calculation settings, use the REST API, where they are documented parameters.