# Kundlit Vedic Astrology (remote · kundlit.com)

Free Vedic astrology: panchang, kundali, transits, matching, doshas, eclipses, numerology

- Trust score: 76/100 (medium)
- Change this week: +7
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `kundlit.com`: 76/100 (this document), [markdown](https://verifymcp.io/servers/com-kundlit-astro/api-mcp.md), [page](https://verifymcp.io/servers/com-kundlit-astro/api-mcp)
- npm · `@kundlit/mcp`: 35/100, [markdown](https://verifymcp.io/servers/com-kundlit-astro/kundlit-mcp.md), [page](https://verifymcp.io/servers/com-kundlit-astro/kundlit-mcp)

## Channel facts

- Endpoint: `https://kundlit.com/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.4.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 74/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 8834 tokens (~464/item across 19 items; 17 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-kundlit-astro https://kundlit.com/api/mcp
```

### Codex

```toml
[mcp_servers.com-kundlit-astro]
url = "https://kundlit.com/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-kundlit-astro": {
      "type": "remote",
      "url": "https://kundlit.com/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-kundlit-astro --url https://kundlit.com/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-kundlit-astro:
    url: "https://kundlit.com/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-kundlit-astro": {
      "type": "http",
      "url": "https://kundlit.com/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 74, +3)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 70, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “get_sade_sati” rewrote its description, which is the text the model reads
- [security] Tool “get_panchang” rewrote its description, which is the text the model reads
- [security] Tool “get_pancha_pakshi” rewrote its description, which is the text the model reads
- [security] Tool “get_muhurta_timings” rewrote its description, which is the text the model reads
- [security] Tool “get_janam_kundali” rewrote its description, which is the text the model reads
- [security] Tool “get_eclipses” rewrote its description, which is the text the model reads
- [security] Tool “get_dasha_periods” rewrote its description, which is the text the model reads
- [security] Tool “check_manglik” rewrote its description, which is the text the model reads
- [security] Tool “check_kaal_sarp” rewrote its description, which is the text the model reads
- [security] Tool “get_year_events” rewrote its description, which is the text the model reads
- [security] Tool “get_kundli_match” rewrote its description, which is the text the model reads
- [security] Tool “get_numerology” rewrote its description, which is the text the model reads

### 2026-07-27 (score 69, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 69)

First indexed and scored.

## MCP tools (17)

### `get_panchang` (~552 tokens)

Daily Panchang (Hindu almanac)

Returns the Hindu panchang (daily Vedic almanac) for one date at one place: the five angas (tithi with paksha, nakshatra, yoga, karana, vara with its weekday lord) each with its end time, the lunar month with adhika-masa flag, sunrise/sunset/moonrise/moonset, abhijit muhurta, the auspicious choghadiya windows, and the inauspicious periods (rahu kaal, yamaganda, gulika kala). Use this for 'what is today's panchang / tithi / nakshatra' questions. If the user wants the FULL timing surface (all 16 choghadiya, the 24 horas, varjyam, bhadra, panchak, brahma muhurta) to choose a moment for an activity, call get_muhurta_timings instead. Nakshatra here is the DAY's nakshatra, not a person's birth star -- for that use get_birth_details. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Any city worldwide; window times derive from that location's actual sunrise and sunset, so they differ city to city on the same date.

Input parameters:

- `date` (string): Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit to get today's date at the given place (not the server's date).
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_janam_kundali` (~624 tokens)

Janam Kundali (Vedic birth chart)

Returns a full Vedic birth-chart (janam kundali) summary for one person from their birth date, time and place: the lagna (ascendant) with sign, nakshatra, pada and lord; all nine grahas with sidereal sign, house, nakshatra, pada, dignity and retrograde/combust flags; the currently running Vimshottari mahadasha and antardasha with end dates, omitted only for a chart cast at the present moment, where no dasha has yet elapsed; and the most notable classical yogas detected, with a count of how many were found in all. Use this when the user wants their whole chart read. Prefer the cheaper, narrower sibling when the question is narrow: get_birth_details for only nakshatra / moon sign / lagna, get_dasha_periods for the full dasha timetable, get_upapada_arudha for the Jaimini layer, get_transits for where the planets are RIGHT NOW rather than at birth. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. Accuracy depends on birth-time precision.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_kundli_match` (~282 tokens)

Kundli Milan (Ashtakoot compatibility)

Returns classical Ashtakoot marriage compatibility (kundli milan / gun milan) between two people from both birth charts: each of the eight koots (varna, vashya, tara, yoni, graha maitri, gana, bhakoot, nadi) with points earned out of its maximum, the total out of 36, any koot-level dosha, the classical cancellation that applies to it if one does, and an overall verdict. Use this whenever real marriage matching is asked for. get_love_compatibility is name-numerology entertainment and is NOT a substitute. Nadi/bhakoot dosha reported here is chart-pair compatibility, not the individual Mars dosha -- for that call check_manglik on each person. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Both people need an exact birth time and place.

Input parameters:

- `person_a` (object, required): First person: gender plus birth date, birth time and place (or coordinates + timezone).
- `person_b` (object, required): Second person: same fields as person_a. Their birth place may differ from person_a's.

### `check_manglik` (~546 tokens)

Manglik (Mangal dosha) check

Returns a yes/no Manglik (Mangal / Mars dosha) verdict for ONE person's birth chart, with severity (none, mild, medium or high), which of the three classical reference points trigger it (Mars counted from the ascendant, from the Moon, from Venus), the classical cancellations that apply, and the traditional remedies for it. Use this for 'am I manglik / do I have mangal dosh' questions, and run it per person before a marriage discussion. It scores ONE chart -- for the two-chart compatibility score use get_kundli_match; for the Rahu-Ketu hemming dosha use check_kaal_sarp. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Remedies are the classical prescriptions, reported as data and not as advice.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_sade_sati` (~615 tokens)

Sade Sati (Saturn transit) status

Returns a person's Sade Sati status -- Saturn's roughly 7.5-year passage over the sign before, the same as, and the sign after their natal Moon: whether it is currently active, the phase (rising / peak / setting) with its start and end dates, the phases still to come, the natal Moon rashi, Saturn's sign now, and dhaiya (small panoti) status. Use this for 'when does my sade sati start/end' and 'am I in shani sade sati' questions. This is Saturn-only; for where ALL nine grahas are transiting now (and their houses from the natal Moon) call get_transits. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Dates are computed, not predicted -- no interpretation of what the period will bring is returned.

Input parameters:

- `as_of_date` (string): Evaluate Saturn's position as of this date, YYYY-MM-DD, years 1200-2400. Omit for today. Use it to ask 'was I in sade sati in 2019' or 'will I be in 2031'.
- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `check_kaal_sarp` (~553 tokens)

Kaal Sarp dosha check

Returns a yes/no Kaal Sarp dosha verdict for ONE birth chart -- the condition where the seven classical grahas all fall on one side of the Rahu-Ketu axis -- plus which of the twelve named types it is (Anant, Kulik, Vasuki, Shankhpal and the rest), whether the hemming is full or partial, the houses involved, and a plain explanation of the finding. Use this for 'do I have kaal sarp dosh' questions. It is a different dosha from the Mars one (check_manglik) and from marriage-pair doshas (get_kundli_match); ask for each separately. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Needs an exact birth time -- partial hemming can flip with a few minutes' error.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_pancha_pakshi` (~615 tokens)

Pancha Pakshi (five-bird) timing

Returns a PERSONAL timing schedule under Tamil Pancha Pakshi Shastra: it resolves the person's birth bird (Vulture, Owl, Crow, Cock or Peacock) from their birth details, then returns that day's ten yaamas -- five by day, five by night -- each with the acting bird and activity and a list of sub-periods carrying a 1-10 strength rating plus that bird's relation (friend / same / enemy) to the person's own bird. Use this when the user wants timings tuned to THEM. get_muhurta_timings and get_panchang give the same day's windows for everyone at that place with no birth details; this system is independent of them and the two can disagree. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa for the birth-bird nakshatra); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Yaama boundaries follow the location's actual sunrise and sunset, so the schedule is place-specific.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `date` (string): Day to schedule, YYYY-MM-DD, years 1200-2400. Omit for today at the given place. The birth fields identify the person; this field picks the day being planned.
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_muhurta_timings` (~670 tokens)

Muhurta timings (good & bad windows)

Returns every auspicious and inauspicious time window for one date at one place, in a single call: all 16 choghadiya with quality, the 24 planetary horas, rahu kaal / yamaganda / gulika kala, abhijit + brahma + vijaya + godhuli + nishita muhurta and the two sandhyas, amrita kalam, varjyam, dur muhurtam, bhadra windows, panchak and gand mool status, and disha shool (the travel direction to avoid that weekday). Use this to CHOOSE a moment -- 'best time to sign / travel / start work today'. Use get_panchang instead when the user only wants the day's tithi and nakshatra; use get_pancha_pakshi when the timing must be personalised from full birth details. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Windows are divisions of that location's actual sunrise-to-sunset day. If a window cannot be computed for the date the result names it under data_note as unknown rather than dropping it -- do not read absence as 'none today'.

Input parameters:

- `date` (string): Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit for today's date at the given place.
- `janma_nakshatra` (string): Birth star in IAST, e.g. "Rohini" or "Ashvini" (spelling is matched loosely). Optional: supply it to add that person's tarabala verdict for the day. Omit and the tarabala block is left out entirely.…
- `janma_rashi` (string): Birth moon sign, Sanskrit or Western -- "Vrishabha" and "Taurus" both work. Optional: supply it to add that person's chandrabala verdict for the day. Omit and the chandrabala block is left out entire…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_year_events` (~469 tokens)

Hindu festival & vrat dates for a year

Returns dated Hindu calendar events for a whole year at one city. category='festival' lists every festival and vrat that year (Holi, Diwali, Navratri, Shivratri and the rest); the other categories list every ekadashi, purnima, amavasya or sankranti date. Each row is the exact local date and the event name, plus a one-line significance on shorter lists. Use this for 'when is X this year' and 'list all ekadashi dates' questions. For the detail of a single day (tithi, sunrise, rahu kaal) call get_panchang with that date; for eclipses call get_eclipses. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and results are computed for the nearest of 50 supported cities (a location_note names it when the snap is far); long lists are capped at 80 rows, so pass month to page through them.

Input parameters:

- `category` (string, required): "festival" returns every event of the year; "ekadashi", "purnima", "amavasya" and "sankranti" each narrow the list to that lunar/solar family only.
- `month` (integer): Restrict the result to a single Gregorian month, 1 = January to 12 = December. Omit for the whole year. Use it when a year-wide list came back truncated.
- `place` (string): City as free text, e.g. "Jaipur" or "Chennai, India". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities, since tithi-based dates can differ by a day between distant longit…
- `year` (integer, required): Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected.

### `get_eclipses` (~339 tokens)

Solar & lunar eclipses for a year

Returns every solar and lunar eclipse of a calendar year with local visibility for one city: eclipse type (total, partial, annular or penumbral), date, the sparsha (first contact), madhya (maximum) and moksha (release) times, the magnitude, and a locally_visible flag. That flag is the one that matters for practice -- sutak observance applies only where the eclipse is actually visible. Use this for 'which eclipses fall in this year' and 'is it visible here' questions, and for sutak timing. For festivals and vrat dates use get_year_events; for the rest of a day's almanac use get_panchang. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and visibility is evaluated for the nearest of 50 supported cities.

Input parameters:

- `place` (string): City as free text, e.g. "Jaipur" or "Chennai, India". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities; visibility and contact times are reported for that city.
- `year` (integer, required): Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected.

### `get_numerology` (~319 tokens)

Vedic numerology from date of birth

Returns a Vedic numerology reading from a date of birth alone: the mulank (root / psychic number, from the day of the month) and the bhagyank (destiny / life-path number, from the whole date), each with its ruling planet and traditional meaning, plus the classical lucky attributions -- numbers, colours, weekday, direction, gemstone. Optionally adds the Chaldean naam-ank when a name is supplied. Use this when the user asks about their number, life path or lucky colour/day/stone. It is NOT astrology and shares nothing with the chart tools: for a birth chart use get_janam_kundali, for a birth star use get_birth_details. Read-only deterministic arithmetic over the classical Chaldean number table -- no ephemeris is touched, and the result's Source line says so. No writes, no auth, at least 30 requests/min/IP per server instance. Birth time and place are not used, so none is asked for.

Input parameters:

- `birth_date` (string, required): Date of birth as YYYY-MM-DD, e.g. 1992-03-14. Must be a real calendar date. Birth time, timezone and place have no effect in numerology and are not accepted.
- `name` (string): Full name in Latin letters, e.g. "Rahul Sharma" -- it must contain at least one A-Z letter. Optional: supply it to add the Chaldean name number and its meaning; omit and only the date-derived numbers…

### `get_love_compatibility` (~234 tokens)

Love compatibility by name numerology

Returns a light-hearted name-compatibility score between two people from Pythagorean numerology: each name reduces to a digit 1-9 (any master number 11/22/33 is reported alongside), the pair maps to a 0-100 score, and a short fixed reading and band come with it. Use this ONLY for entertainment, and say so when presenting it. It uses names, not birth data, so it can say nothing real about a relationship: for genuine marriage matching call get_kundli_match, which scores both birth charts on the Ashtakoot system. Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no birth details, no writes, no auth, at least 30 requests/min/IP per server instance.

Input parameters:

- `name_a` (string, required): First person's name in Latin letters, e.g. "Rahul". Must contain at least one A-Z letter; digits and punctuation are ignored when scoring.
- `name_b` (string, required): Second person's name in Latin letters, e.g. "Priya". Same rules as name_a.

### `get_mobile_numerology` (~211 tokens)

Mobile number numerology

Returns a numerological reading of a mobile or landline number: the extracted digit string, the digit total, the single 1-9 number it reduces to, the overall vibe that reduced number carries, and the traditional meaning of each distinct digit present. Use this for 'is my phone number lucky' style questions, or when choosing between candidate numbers. It reads a number string only -- nothing about the person -- so for anything tied to a birth date use get_numerology. Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no network lookup of the number, no writes, no auth, at least 30 requests/min/IP per server instance.

Input parameters:

- `mobile_number` (string, required): Phone number in any format -- "+91 98765-43210", "9876543210" and "(020) 7946 0958" all work, since +, spaces, hyphens and brackets are stripped. Must contain at least one non-zero digit.

### `get_birth_details` (~582 tokens)

Birth details (nakshatra, rashi, lagna, navamsa lagna)

Returns just the identity fields of a Vedic birth chart: the Moon's janma nakshatra (birth star) with its 1-27 number and pada, the janma rashi (moon sign) with its classical lord and the house it occupies, the lagna (ascendant) with degree in sign, nakshatra, pada and lord, and the navamsa (D9) lagna with its lord. Use this for the common single questions -- 'what is my nakshatra / rashi / lagna' -- and to fetch janma_nakshatra and janma_rashi values that get_muhurta_timings accepts. It returns NO planet table, no yogas and no dasha: for those call get_janam_kundali (whole chart) or get_dasha_periods (dasha only). Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_dasha_periods` (~601 tokens)

Vimshottari dasha periods

Returns the Vimshottari dasha timetable for one birth chart: the mahadasha, antardasha and pratyantardasha running right now with their end dates, the mahadasha in force at birth with its unexpired balance in years-months-days, and the full nine-mahadasha lifetime timeline with a start and end date per period. For a chart cast at the present moment no dasha has elapsed yet, so the birth mahadasha stands in and the result is flagged is_birth_fallback -- do not report it as a separately computed current period. Use this for 'which dasha am I in', 'when does my Saturn mahadasha start' and any life-period timeline question. It returns dates only -- no interpretation of what a period brings. For the planet placements those dasha lords sit in, call get_janam_kundali. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa) from the Moon's birth nakshatra; no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. Dates shift with birth-time accuracy.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_upapada_arudha` (~615 tokens)

Upapada lagna and arudha padas (Jaimini)

Returns the Jaimini layer of one birth chart: the upapada lagna (UL, the classical marriage anchor) with its sign, lord and cited reading, all twelve arudha padas (A1-A12) with sign and life domain, the eight charakarakas (Atmakaraka, Amatyakaraka and the rest) with the graha holding each, and the karakamsha lagna. The result also lists the classical texts the upapada reading is cited from. Use this only when Jaimini terms are asked for by name -- upapada, arudha, charakaraka, karakamsha -- or for marriage questions read the Jaimini way. The Parashari layer (grahas, houses, dasha, yogas) is in get_janam_kundali; get_kundli_match is the tool for scoring two charts against each other. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. If the engine cannot attach the Jaimini layer the result comes back with partial: true rather than with invented values.

Input parameters:

- `birth_date` (string, required): Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected).
- `birth_time` (string, required): Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minu…
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

### `get_transits` (~702 tokens)

Planetary transits (gochar) now or on a date

Returns where the nine grahas actually are at a moment in time (gochar / transit chart), for a place: each graha's sidereal sign, degree within the sign, nakshatra, pada, retrograde flag, dignity and house from the transit ascendant, plus the transit lagna itself. Defaults to right now at that place. Pass the optional `natal` birth details and the result ALSO counts each transiting graha's whole-sign house from the natal Moon (chandra lagna) -- the frame classical gochar is read in. Use this for 'where is Saturn/Jupiter right now' and 'what is transiting my moon sign' questions. It answers for ONE moment only and returns no ingress, retrograde-station or sign-change dates -- do not scan it across many dates to find them. For the birth chart itself use get_janam_kundali; for dated Saturn phases use get_sade_sati, the one tool here that returns transit date ranges. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all chart tools -- and a call carrying `natal` costs TWO of those, since it computes the natal chart as well. It returns COMPUTED POSITIONS ONLY -- no forecast, horoscope or interpretation text is produced.

Input parameters:

- `date` (string): Date of the transit chart, YYYY-MM-DD, years 1200-2400. Omit for today at the given place. A past or future date gives the positions for that single day.
- `latitude` (number): Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.
- `longitude` (number): Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.
- `natal` (object): Optional birth details of the person the transits are being read for: birth_date, birth_time and a place (or latitude + longitude + timezone). Supply them to add the gochar_from_natal_moon block. Omi…
- `place` (string): Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only…
- `time` (string): Local clock time of the transit chart, HH:MM 24-hour (00:00-23:59). Omit for the current time at the given place. It matters most for the Moon (about 13 degrees a day) and for the transit lagna (a fu…
- `timezone` (string): IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-kundlit-astro/api-mcp#diagnostics

## Score history

- 2026-08-03: 76
- 2026-08-02: 75
- 2026-08-01: 75
- 2026-07-31: 74
- 2026-07-30: 71
- 2026-07-29: 71
- 2026-07-28: 70
- 2026-07-27: 69
- 2026-07-26: 69

## Links

- Remote endpoint: https://kundlit.com/api/mcp
- Repository: https://github.com/puru991/kundlit-mcp
- Website: https://kundlit.com/mcp
- Changelog RSS feed: https://verifymcp.io/servers/com-kundlit-astro/api-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-kundlit-astro/api-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-kundlit-astro/api-mcp