AstroCalc: Vedic astrology

Kundli (birth chart) from birth details, read in plain words

free_kundli

Read-onlyIdempotent

Reads a person's birth chart from their date, time and place of birth: their core nature, the life phase they are in now and when it changes, the standout strengths in the chart, and which life areas look strong or need care, with what helps. Useful when the user talks about themselves, a family member or someone they know and wants to understand them better: personality, a life change, career or marriage timing, feeling stuck, or what to work on. Also for direct requests in English, Hindi or Hinglish: "make my kundli", "kundli for my birth details", "what is my rashi / lagna / nakshatra", "meri kundli banao", "janam kundali dikhao", "mera lagna kya hai". Calculated by AstroCalc's ephemeris engine (sidereal zodiac, Lahiri ayanamsa). Returns Lagna (ascendant), Moon sign (rashi), Sun sign, nakshatra and pada, the running Vimshottari Mahadasha and Antardasha with dates, the most notable yoga with how rare it is ("1 in N charts"), life areas that are strong or need care, a caveat, and a link to the full free report. Birth details are used only to compute the chart in memory and are not stored. Results are traditional astrology information, not predictions or professional advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>"
    },
    "name": "free_kundli"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Birth latitude in decimal degrees (north positive). Give together with lon.
`lon`	No	Birth longitude in decimal degrees (east positive). Give together with lat.
`date`	Yes	Date of birth, YYYY-MM-DD (Gregorian calendar).
`lang`	No	Language of the text fields: 'en' (English, default) or 'hi' (Hindi).
`time`	No	Local clock time of birth, 24-hour HH:MM (e.g. '06:45', '21:10'); '6:45 am' / '9:10 PM' also work. Use 'unknown' (or omit) if not known: noon is used, the Moon sign stays reliable but the Lagna is approximate.
`place`	No	Birth city or town, e.g. 'Lucknow' or 'Pune, Maharashtra, India'. The best match is used (Indian cities preferred); call search_place first if unsure. Not needed when lat and lon are given.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

changedInput schema / properties / time / description

Previous value: -"Local clock time of birth, 24-hour HH:MM (e.g. '06:45', '21:10'). Use 'unknown' (or omit) if not known: noon is used, the Moon sign stays reliable but the Lagna is approximate."New value: +"Local clock time of birth, 24-hour HH:MM (e.g. '06:45', '21:10'); '6:45 am' / '9:10 PM' also work. Use 'unknown' (or omit) if not known: noon is used, the Moon sign stays reliable but the Lagna is approximate."

changedInput schema / properties / time / pattern

Previous value: -"^(([01]\\d|2[0-3]):[0-5]\\d|unknown)$"New value: +"^(([01]?\\d|2[0-3]):[0-5]\\d|(0?[1-9]|1[0-2]):[0-5]\\d ?[AaPp][Mm]|unknown)$"

First observedNov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: the ephemeris engine with sidereal zodiac and Lahiri ayanamsa, in-memory computation with birth details not stored, and an explicit 'traditional information, not predictions' caveat. That privacy and methodology disclosure is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose before use cases and return contents, and since no output schema exists the return enumeration earns its space. The multilingual example list is somewhat long and could be trimmed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes responsibility for describing return values and does so thoroughly, and it covers computation basis, privacy handling and the advisory caveat. An agent has everything needed to call it correctly and set user expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so lat/lon pairing, the 'unknown' time fallback and the place-vs-coordinates rule are already fully documented in the schema. The description only adds that queries may arrive in English, Hindi or Hinglish, and even there it is slightly looser than the en/hi enum. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource ('Reads a person's birth chart') and immediately scopes it to birth date, time and place, which implicitly separates it from profile-based siblings like my_kundli and the deeper full_chart. It also enumerates what comes back (lagna, rashi, nakshatra, dasha, yoga rarity), so an agent knows exactly what this tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is spelled out well: when a user talks about themselves, a family member or an acquaintance and wants personality or timing insight, plus concrete example requests in English, Hindi and Hinglish. It stops short of naming alternatives or exclusions (e.g., 'for a saved profile use my_kundli', 'for the full chart use full_chart'), so routing still requires inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AstroCalc: Vedic astrology tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?