# Vedic Astrology MCP Server — Jagannatha Hora calculation engine

> 32 read-only Model Context Protocol tools over the Jagannatha Hora Vedic astrology (Jyotish) engine: birth chart, 55 dasha systems, 23 divisional charts, yogas, doshas, ashtakavarga, transits, muhurta and marriage matching. No API key, no install — connect over HTTP.

HTML version:  https://horoscopes.today/mcp
Tool manifest: https://horoscopes.today/mcp-tools.json
REST API:      https://horoscopes.today/api
Endpoint:      https://jagannatha-hora-359167915530.europe-west1.run.app/mcp
Last verified against the service source: 2026-08-31

## What MCP is

The Model Context Protocol is an open standard for letting a language model call external tools. 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. Every tool is read-only — each computes and returns; none write, send, charge or change anything.

## Connect

- Server name: Jagannatha Hora MCP Server
- Server version: 1.0.0
- Endpoint: https://jagannatha-hora-359167915530.europe-west1.run.app/mcp
- Transport: JSON-RPC 2.0 over HTTP (POST), with an optional SSE stream
- Protocol revision: 2024-11-05
- Authentication: none — no key, no token, no OAuth
- Health check: https://jagannatha-hora-359167915530.europe-west1.run.app/mcp/health
- SSE stream: https://jagannatha-hora-359167915530.europe-west1.run.app/mcp/sse

### 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. Every response is deterministic, so caching on your side is safe.

Client support for remote MCP servers moves quickly and differs between products and versions. The durable answer: this 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

```bash
curl -sS "https://jagannatha-hora-359167915530.europe-west1.run.app/mcp/health"

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":{}}'
```

## Protocol

| Method | What it does |
| --- | --- |
| `initialize` | Handshake. Returns protocolVersion, capabilities ({"tools": {"listChanged": false}}) and serverInfo. The server echoes back whatever protocolVersion the client sent, falling back to 2024-11-05 when the client sends none. |
| `tools/list` | The authoritative tool inventory with full JSON Schemas. Call this rather than trusting any written list, including this page. |
| `tools/call` | Runs one tool. Takes name and arguments. The result comes back as MCP content: a single text part whose text is the JSON-encoded result object. |
| `ping` | Returns an empty object. Liveness. |
| `notifications/*` | Accepted and acknowledged with no response body, per JSON-RPC notification semantics. |

### Transport

- The transport is JSON-RPC 2.0 over HTTP. POST your request to the endpoint and the JSON-RPC response comes straight back in the body — no session, no handshake beyond initialize.
- An SSE variant exists for clients that want it: GET /mcp/sse with Accept: text/event-stream opens the stream, which emits an endpoint event followed by a session event carrying the session id. Messages are then POSTed with an X-MCP-Session-ID header and the reply is pushed down the stream as a message event, with the POST itself returning 202. A keepalive comment goes out every 25 seconds.
- This is the HTTP + SSE shape of the 2024-11-05 protocol revision. It is not a stdio server: there is no command to spawn and no package to install.

### Errors

| Code | Meaning | When |
| --- | --- | --- |
| `-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, an unknown tool name, or birth details that fail to parse — a missing required field names the fields it is missing. |
| `-32603` | Internal error | The tool raised. The message carries the reason. |

## Shared inputs

Most tools identify a chart with the same six fields:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `date` | string | Yes | `—` | Birth date in YYYY-MM-DD format, e.g. 1985-06-15 |
| `time` | string | Yes | `—` | Birth time in 24h HH:MM:SS format, e.g. 10:30:00. Shorter forms are normalised server-side. |
| `latitude` | number | Yes | `—` | Birth-place latitude in decimal degrees, e.g. 13.0827 |
| `longitude` | number | Yes | `—` | Birth-place longitude in decimal degrees, e.g. 80.2707 |
| `timezone` | number | Yes | `—` | Timezone offset from UTC in hours, e.g. 5.5 for IST |
| `place` | string | No | `null` | Optional birth-place name, cosmetic only. |

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

### Event location override

`get_gochara`, `get_gochara_range` and `get_muhurta` also accept an event location. Every field is optional and falls back to the corresponding birth value.

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `event_place` | string | No | `null` | Event place name; defaults to the birth place. |
| `event_latitude` | number | No | `null` | Event latitude; defaults to the birth latitude. |
| `event_longitude` | number | No | `null` | Event longitude; defaults to the birth longitude. |
| `event_timezone` | number | No | `null` | Event timezone offset from UTC; defaults to the birth timezone. |
| `event_elevation` | number | No | `null` | Event elevation in metres; defaults to the birth elevation. |

## All 32 tools

| Tool | Category | Birth details | What it does |
| --- | --- | --- | --- |
| `generate_horoscope` | Chart and positions | Yes | The entry point. Computes the chart, then returns a compact overview — the birth details it used, the ascendant and Moon nakshatra with padas and lord, calendar info, and the list of section names every other tool can then fetch. Start here; the chart is cached, so the follow-up calls are cheap. |
| `get_amsa_rulers` | Divisional charts | Yes | The Nadiamsa (D-150) ruler for every point in the chart — planets, upagrahas, lagnas, varnada and sphutas. |
| `get_arudha_padas` | Chart and positions | Yes | The arudha padas — the perceived, as-others-see-it houses — for a chosen divisional chart. |
| `get_ashtakavarga` | Strength and ashtakavarga | Yes | Ashtakavarga bindu scores with the rows labelled by planet instead of returned as bare arrays: binna (the un-reduced BAV), sodhita (SoAV, the reduced grid the pindas come from), samudhaya (SAV), and the rasi, graha and sodhya pindas. The prastara grid is deliberately left out to keep the payload small. |
| `get_bhava_bala` | Strength and ashtakavarga | Yes | Bhava Bala — house strength — parsed into House 1 through House 12, each with total virupas, rupas and a strength ratio. |
| `get_chandra_arudhas` | Chart and positions | Yes | The arudha signs of the twelve houses counted from the Moon. |
| `get_chara_karakas` | Chart and positions | Yes | The eight Jaimini chara (variable) karakas — Atma, Amatya, Bhratri and the rest — assigned by planetary degree. |
| `get_dasha` | Timing and dashas | Yes | Any of 55 dasha systems as a nested tree, with the running period marked. Vimshottari by default; ask for a specific maha or antar to drill into one branch instead of the current one. |
| `get_divisional_chart` | Divisional charts | Yes | One varga chart by name, with every body's sign and longitude in that division. |
| `get_doshas` | Yogas, doshas and longevity | Yes | The standard dosha checks for the chart — Manglik, Kaal Sarp and the rest of the set. |
| `get_gochara` | Transits and muhurta | Yes | A transit snapshot for one target date read against the natal chart: panchanga, muhurta windows, all nine planets with their house from the natal Moon and Lagna, and the person-relative strengths (Tara Bala, Chandra Bala, Sade Sati). |
| `get_gochara_range` | Transits and muhurta | Yes | The same natal transit detail for every day in a range, in one call — no scoring, no verdict, so the model reasons over the raw days itself. The natal reference is computed once. |
| `get_graha_arudhas` | Chart and positions | Yes | The arudha — the reflected sign — of each graha and of the lagna. |
| `get_house_varnadas` | Chart and positions | Yes | The varnada lagna for each of the twelve houses. |
| `get_longevity` | Yogas, doshas and longevity | Yes | Classical Ayurdaya longevity reference computations — the band and the combinations that produced it. |
| `get_marriage_match` | Compatibility | No | Compatibility for a couple under the North Indian Ashtakoota system, the South Indian ten-porutham system, or both. Returns a summary block with each side's score, rating and Manglik state, plus the full detail. |
| `get_muhurta` | Transits and muhurta | Yes | Ranks the days in a window for a specific event, scoring the classical factors and the native's own strength on each day, and returning the score breakdown, the weights used, and the best and avoid clock windows. It ranks; it does not choose. |
| `get_nakshatra_pada` | Chart and positions | Yes | Nakshatra, pada, nakshatra lord and degrees-into-nakshatra for every body in the chart. |
| `get_other_bala` | Strength and ashtakavarga | Yes | The remaining strength measures — harsha, pancha and dwadhasa vargeeya bala. |
| `get_planet_ingress` | Transits and muhurta | No | Retrograde-aware sign-change timing across a date range. Takes no birth details at all — ingresses are the same for everyone. |
| `get_planetary_states` | Chart and positions | Yes | Dignity and condition flags for the planets — retrograde, combust, exalted, debilitated and the rest. |
| `get_sahams` | Chart and positions | Yes | The sahams — the Vedic Arabic parts — of the chart. |
| `get_saturn_transit` | Transits and muhurta | Yes | Saturn's Sade Sati windows and the related 4th and 8th house transits. |
| `get_shad_bala` | Strength and ashtakavarga | Yes | Shadbala, the six-fold planetary strength, with each component labelled by planet: sthana, kala, dig, cheshta, naisargika and drik bala, plus total virupas, total rupas and the strength ratio. |
| `get_special_lagnas` | Chart and positions | Yes | The special and derived lagnas — Bhava, Hora, Ghati and the others. |
| `get_sphutas` | Chart and positions | Yes | The special sphutas — the sensitive computed points of the chart. |
| `get_surya_arudhas` | Chart and positions | Yes | The arudha signs of the twelve houses counted from the Sun. |
| `get_upagrahas` | Chart and positions | Yes | The upagrahas — the shadowy sub-planets such as Gulika and Mandi. |
| `get_vaiseshikamsa_bala` | Strength and ashtakavarga | Yes | Vaiseshikamsa Bala — the count of good vargas each planet occupies. |
| `get_vimsopaka_bala` | Strength and ashtakavarga | Yes | Vimsopaka Bala — divisional-chart dignity strength on a twenty-point scale. |
| `get_yogas` | Yogas, doshas and longevity | Yes | Every yoga detected in the chart, each with its classical definition and stated effects. |
| `list_divisional_charts` | Divisional charts | No | The discovery tool: the menu of the 23 varga charts, each with the token to request it by, its name and what it is classically read for. Takes no parameters and no birth details. |

### What a tool call returns

A `tools/call` result is MCP content: a single text part whose text is the JSON-encoded result object. Thirty-one of the 32 tools wrap their payload 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.

## Tool parameters

Defaults below 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.

### get_arudha_padas

The arudha padas — the perceived, as-others-see-it houses — for a chosen divisional chart.

Takes the shared birth-details block, plus:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `varga` | string | No | `"D-1"` | One of: D-1, D-2, D-3, D-4, D-5, D-6, D-7, D-8, D-9, D-10, D-11, D-12, D-16, D-20, D-24, D-27, D-30, D-40, D-45, D-60, D-81, D-108, D-144. |

Returns: section "arudha_padhas" (the engine spelling, with the h), plus the varga that was applied

### get_dasha

Any of 55 dasha systems as a nested tree, with the running period marked. Vimshottari by default; ask for a specific maha or antar to drill into one branch instead of the current one.

Takes the shared birth-details block, plus:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `system` | string | No | `"vimsottari"` | One of 55 values — 28 graha systems plus 27 rasi systems, both listed below. |
| `as_of_date` | string | No | `today` | YYYY-MM-DD. "YYYY-MM-DD HH:MM" and "YYYY-MM-DD HH:MM:SS" are also parsed. |
| `depth` | integer | No | `3 for graha systems, 2 for rasi systems` | 1 to 4. Clamped to that range, and reduced to what the chosen system can actually produce. |
| `maha` | string | No | `null` | Ruler name of the maha dasha to expand. No enum — the valid set is the chosen system's rulers (planets or signs). |
| `antar` | string | No | `null` | Ruler name of the antar dasha to expand. Requires maha to be set. |

Returns: section "dasha". The data carries dasha_type, system, as_of, depth, levels_available and maha_timeline, plus current_maha / current_antar / current_pratyantar when they apply.

### get_divisional_chart

One varga chart by name, with every body's sign and longitude in that division.

Takes the shared birth-details block, plus:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `varga` | string | No | `"D-1_rasi"` | One of: D-1, D-2, D-3, D-4, D-5, D-6, D-7, D-8, D-9, D-10, D-11, D-12, D-16, D-20, D-24, D-27, D-30, D-40, D-45, D-60, D-81, D-108, D-144. The resolver is forgiving — "D9", "9" and "navamsa" all reach D-9. An unknown value returns an error object listing the available vargas rather than failing the call. |

Returns: section "divisional_charts", plus the engine key that was matched (e.g. "D-9_navamsa")

### get_gochara

A transit snapshot for one target date read against the natal chart: panchanga, muhurta windows, all nine planets with their house from the natal Moon and Lagna, and the person-relative strengths (Tara Bala, Chandra Bala, Sade Sati).

Takes the shared birth-details block, plus:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `target_date` | string | Yes | `—` | The transit date, YYYY-MM-DD. |
| `target_time` | string | No | `"12:00:00"` | HH:MM:SS; local noon by default. |
| `include` | string[] | No | `["ashtakavarga", "gochara_phala", "transit_charts"]` | Enrichment sections. Omit for all three; pass [] for the lean snapshot. |
| `node_type` | string | No | `"mean"` | "mean" or "true". |
| `event_place` | string | No | `null` | Event place name; defaults to the birth place. |
| `event_latitude` | number | No | `null` | Event latitude; defaults to the birth latitude. |
| `event_longitude` | number | No | `null` | Event longitude; defaults to the birth longitude. |
| `event_timezone` | number | No | `null` | Event timezone offset from UTC; defaults to the birth timezone. |
| `event_elevation` | number | No | `null` | Event elevation in metres; defaults to the birth elevation. |

Returns: section "gochara"

### get_gochara_range

The same natal transit detail for every day in a range, in one call — no scoring, no verdict, so the model reasons over the raw days itself. The natal reference is computed once.

Takes the shared birth-details block, plus:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `from_date` | string | Yes | `—` | Range start, YYYY-MM-DD. |
| `to_date` | string | Yes | `—` | Range end, YYYY-MM-DD. Maximum 60 days; a longer range is an error. |
| `time_of_day` | string | No | `"12:00:00"` | The time used for each day. |
| `include` | string[] | No | `["ashtakavarga", "gochara_phala"]` | Two sections here by default, not the three get_gochara defaults to. Pass [] for the lean snapshot. |
| `event_place` | string | No | `null` | Event place name; defaults to the birth place. |
| `event_latitude` | number | No | `null` | Event latitude; defaults to the birth latitude. |
| `event_longitude` | number | No | `null` | Event longitude; defaults to the birth longitude. |
| `event_timezone` | number | No | `null` | Event timezone offset from UTC; defaults to the birth timezone. |
| `event_elevation` | number | No | `null` | Event elevation in metres; defaults to the birth elevation. |

Returns: section "gochara_range" — range, place, ayanamsa_mode, natal_ref, count and days

### get_marriage_match

Compatibility for a couple under the North Indian Ashtakoota system, the South Indian ten-porutham system, or both. Returns a summary block with each side's score, rating and Manglik state, plus the full detail.

Takes no birth-details block. Its full parameter list:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `boy` | object | Yes | `—` | date, time, latitude, longitude, timezone (required) and place (optional). |
| `girl` | object | Yes | `—` | Same shape as boy. |
| `system` | string | No | `"both"` | "both", "north" or "south". Choosing one drops the other block from the response. |

Returns: section "marriage_match"

### get_muhurta

Ranks the days in a window for a specific event, scoring the classical factors and the native's own strength on each day, and returning the score breakdown, the weights used, and the best and avoid clock windows. It ranks; it does not choose.

Takes the shared birth-details block, plus:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `event_type` | string | Yes | `—` | One of six: griha_pravesha_own, griha_pravesha_rented, travel_prayana, vehicle_purchase, business_shop_opening, property_purchase_registration. |
| `from_date` | string | Yes | `—` | Scan start, YYYY-MM-DD. |
| `to_date` | string | Yes | `—` | Scan end, YYYY-MM-DD. Maximum 90 days. |
| `day_part_resolution_minutes` | integer | No | `15` | Time-of-day granularity. The tool description states 5-60; the JSON schema declares no minimum or maximum, so treat 5-60 as the supported range rather than an enforced one. |
| `respect_inauspicious_windows` | boolean | No | `true` | Report the Rahu, Gulika and Yamaganda windows to avoid. |
| `event_place` | string | No | `null` | Event place name; defaults to the birth place. |
| `event_latitude` | number | No | `null` | Event latitude; defaults to the birth latitude. |
| `event_longitude` | number | No | `null` | Event longitude; defaults to the birth longitude. |
| `event_timezone` | number | No | `null` | Event timezone offset from UTC; defaults to the birth timezone. |
| `event_elevation` | number | No | `null` | Event elevation in metres; defaults to the birth elevation. |

Returns: section "muhurta" — event_type, event_label, range, rules_applied, weights and the scored candidates

### get_planet_ingress

Retrograde-aware sign-change timing across a date range. Takes no birth details at all — ingresses are the same for everyone.

Takes no birth-details block. Its full parameter list:

| Parameter | Type | Required | Default | Notes |
| --- | --- | --- | --- | --- |
| `planets` | string[] | No | `["Saturn", "Jupiter", "Rahu", "Ketu"]` | An unrecognised planet name is an error. |
| `from_date` | string | Yes | `—` | Range start, YYYY-MM-DD. |
| `to_date` | string | Yes | `—` | Range end, YYYY-MM-DD. Maximum about five years. |
| `timezone` | number | No | `0.0` | Offset used to express the crossing dates. Defaults to UTC — this is NOT a birth timezone and is optional here. |
| `ayanamsa_mode` | string | No | `"LAHIRI"` | Ayanamsa mode. |

Returns: section "planet_ingress" — range, timezone, ayanamsa_mode, planets and ingresses

### The 55 dasha systems

`get_dasha` accepts any of these as `system`. 28 graha (planetary) systems:

```
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
```

27 rasi (sign) systems, which run shallower — hence the default depth of 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
```

## Worked example

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?" Three calls.

### Step 1 — establish the chart

```json
POST https://jagannatha-hora-359167915530.europe-west1.run.app/mcp

{
  "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,
      "longitude": 76.1,
      "timezone": 5.5
    }
  }
}
```

This is the expensive step and it populates the server's chart cache, so every later call for the same birth details is a lookup rather than a recomputation. The result carries `birth_details`, a `summary` (ascendant and Moon nakshatra with padas and lord), `calendar_info`, and `available_sections`.

### Step 2 — the running dasha

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

The server marks which maha, antar and pratyantar contain today's date, so the model does not have to do date arithmetic over a period tree.

### Step 3 — the Saturn question

"Is Saturn giving me trouble" is a Sade Sati question, so call `get_saturn_transit` directly rather than inferring it from planetary positions.

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

Three calls, and the model has the running period with its end date and the Saturn transit windows — the two things the question turned on. The shape matters more than the specifics: do not call `generate_horoscope` and then ask the model to find the answer inside it. Establish the chart, then call the one or two tools that own the question.

## 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 mutates anything. An agent can call any of them without a confirmation step.

### The chart is cached, so slice freely

The expensive step is computing the chart, not slicing it. The server keeps a small in-process LRU of parsed charts — 15 entries, with a 10-minute TTL that refreshes on every hit — keyed by the birth details and the calculation settings. So the intended pattern is one generate_horoscope followed by as many section tools as the question needs, not one call that drags 3.5 MB back to the model. Cache statistics are exposed at GET /mcp/health.

### No authentication

The MCP router enforces no authorization header today. 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 be satisfied by this one. Do not send anything you would not put in a public request.

### Rate limits apply here too

The MCP router runs inside the same FastAPI app as the REST API, so the app-wide default of 200 requests per minute per IP governs it. The per-endpoint REST limits do not apply to tool calls; the default does.

### tools/list is the contract

The registry discovers tools by importing every module in its tools package at startup, so the live set can differ from any written list. Call tools/list at connect time and use the schemas it returns. This page is a snapshot for humans and crawlers; the server is the authority.

### Undocumented parameters exist — do not rely on them

The birth parser accepts calculation settings that appear in no advertised schema: elevation, ayanamsa_mode, ayanamsa_value, calculation_type, bhava_madhya_method, language, pravesha_type, years, months, sixty_hours, tamil_month_method and kali_start_year. They work, but they are not part of the published contract and could change without notice. Send only what tools/list advertises. If you need a non-default ayanamsa today, the REST API exposes it as a supported, documented parameter.

## See also

- REST API reference: https://horoscopes.today/api (Markdown: https://horoscopes.today/api.md, OpenAPI: https://horoscopes.today/openapi.json)
- Free birth chart workspace: https://horoscopes.today/birth-chart