Free Vedic astrology computation for AI assistants over the Model Context Protocol: daily panchang and muhurta timings for any city, janam kundali birth charts, kundli milan (ashtakoot) matching, dosha checks, dasha periods, transits, festival and eclipse calendars, and Vedic numerology — 17 tools (discovered dynamically), plus prompts and documentation resources.
Results are deterministic — computed live with the Swiss Ephemeris on the sidereal zodiac (Lahiri ayanamsa) — and backed by classical-text citations on kundlit.com.
Server URL: https://kundlit.com/api/mcp (hosted, Streamable HTTP)
Auth: none — no account, no API key
Rate limit: 30 requests/minute/IP
Docs: https://kundlit.com/mcp
Privacy: https://kundlit.com/privacy · Support: support@kundlit.com
npx (works with every client, including stdio-only ones)npx -y @kundlit/mcpThat starts a local stdio MCP server which proxies to the hosted endpoint. Point any client at it by command:
Claude Desktop — claude_desktop_config.json:
{
"mcpServers": {
"kundlit-astro": {
"command": "npx",
"args": ["-y", "@kundlit/mcp"]
}
}
}Cursor — .cursor/mcp.json, or any client that reads a generic
.mcp.json:
{
"mcpServers": {
"kundlit-astro": {
"command": "npx",
"args": ["-y", "@kundlit/mcp"]
}
}
}Installed globally (npm i -g @kundlit/mcp) the binary is kundlit-mcp, so
"command": "kundlit-mcp" with no args works too.
No bridge process needed — connect straight to the URL.
Claude Code:
claude mcp add --transport http kundlit https://kundlit.com/api/mcpConfig file:
{
"mcpServers": {
"kundlit-astro": {
"type": "http",
"url": "https://kundlit.com/api/mcp"
}
}
}Claude (web/desktop): Settings → Connectors → Add custom connector →
https://kundlit.com/api/mcp
Full per-client instructions, example prompts and limitations: https://kundlit.com/mcp
Related MCP server: VedAstro MCP Server
The npm package @kundlit/mcp published from here is a thin client: a
bidirectional JSON-RPC pump between a local StdioServerTransport and a
StreamableHTTPClientTransport aimed at https://kundlit.com/api/mcp. It
contains no astrology logic and no copy of the tool list, so tools added or
renamed on the hosted server are picked up with no package update.
Frames are forwarded unmodified in both directions with one deliberate
exception: if the hop to the hosted server fails, the bridge answers the
pending request locally with a JSON-RPC -32001 error (bin/cli.js) rather
than letting the local client hang forever on a reply that is never coming.
That error is synthesised by the bridge and was never sent by the server.
The astrology server itself is hosted at kundlit.com and its source is not
public. The manifests here (.mcp.json, server.json, .claude-plugin/plugin.json)
exist so MCP clients, registries and directories can discover and install it.
kundlit-mcp [--url <endpoint>]
--url <endpoint> Hosted MCP endpoint (default https://kundlit.com/api/mcp).
Also settable via KUNDLIT_MCP_URL; --url wins.
-h, --help Usage and a config snippet.
-v, --version Package version.stdout carries JSON-RPC and nothing else; all diagnostics, including --help
and --version output, go to stderr. Requires Node.js 18 or newer.
docker build -t kundlit-mcp .
docker run -i --rm kundlit-mcpThe container speaks MCP over stdio, so run it with -i and no TTY.
npm install
node scripts/smoke.mjs # end-to-end check against the live hosted server17 tools, discovered dynamically via tools/list — panchang, muhurta and
choghadiya windows, janam kundali, ashtakoot matching, manglik / kaal sarp /
sade sati checks, dasha periods, transits, pancha pakshi, year events,
eclipses, and numerology. Prompts and documentation resources
(kundlit://docs/methodology, kundlit://docs/usage-guide) are likewise
discovered at runtime; ask your client to list them rather than relying on a
list in this README.
"What is today's panchang in Jaipur? When is rahu kaal?"
"Make a janam kundali for 14 March 1992, 6:45 am, Lucknow — which mahadasha am I running?"
"Find me a good time tomorrow in Pune to sign a lease — avoid rahu kaal and bhadra."
"All ekadashi dates in 2026 for Varanasi."
Free-text place (any city worldwide) is preferred; latitude/longitude/IANA
timezone also accepted. Year tools snap to the nearest of 50 supported cities.
Results are informational and not a substitute for professional advice.
Every result carries a Source: attribution line — please keep it intact;
that attribution is the price of free access.
MIT — see LICENSE.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description adds that it is a deterministic computation using Swiss Ephemeris and Lahiri ayanamsa, mentions no writes or auth, and specifies rate limits (30 requests/min/IP per server instance, plus shared engine budget of 60/min/IP). This adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of dense but well-organized information. It is front-loaded with the main verdict and types, and covers usage, behavior, and constraints. A bit more structure (e.g., separate sentences for different aspects) could improve readability, but it is effective and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (yes/no, type, hemming, houses, explanation). It covers computational details, rate limits, and the need for exact birth time. For a tool with 6 parameters and no output schema, this is complete and provides all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the description doesn't need to add much, but it provides extra context: it notes that partial hemming can flip with time errors, and clarifies the coordinate/timezone alternative for the place parameter. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a yes/no Kaal Sarp dosha verdict for one birth chart, plus the specific type, hemming status, houses involved, and a plain explanation. It distinguishes itself from sibling tools like check_manglik and get_kundli_match by explicitly naming them as different doshas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for do I have kaal sarp dosh questions' and provides clear guidance on when not to use it (for manglik or kundli match, use separate tools). It also warns that partial hemming can flip with a few minutes' error, emphasizing the need for exact birth time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds 'Read-only deterministic computation', 'no writes, no auth', specific rate limits (30/min/IP per instance, 60/min/IP shared engine budget), and clarifies that remedies are 'reported as data not advice'. This extends well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise but covers all necessary aspects. It is front-loaded with the primary purpose, then includes usage guidance, sibling distinctions, and behavioral details. A few sentences could be trimmed, but overall it is well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description thoroughly explains what is returned (yes/no, severity levels, reference points, cancellations, remedies). It also covers input constraints (required fields, place vs. coordinates), rate limits, and engine budgets. It provides complete context for an agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 6 parameters. The tool description does not add new meaning beyond what the schema already provides; it only reiterates usage context. Baseline score of 3 is appropriate as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and the specific resource 'Manglik verdict for ONE person's birth chart', listing all output components (yes/no, severity, reference points, cancellations, remedies). It distinguishes from sibling tools like get_kundli_match and check_kaal_sarp, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('am I manglik' questions, before marriage discussion) and when not to (use get_kundli_match for two-chart compatibility, check_kaal_sarp for Rahu-Ketu dosha). Also provides rate limits and auth/engine constraints, giving clear guidance on appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses; no writes, no auth; rate limits per server instance. Annotations already declare readOnly and idempotent, but description enriches understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single well-structured paragraph, front-loaded with returns, then usage, then limitations, then behavioral notes. Every sentence earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thorough explanation of all 6 parameters, despite no output schema. Covers parameter dependencies (place vs lat/lng/timezone), purpose, limitations, rate limits, and sibling tool comparisons. Complete for a read-only deterministic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds extra meaning: explains place format, clarifies that birth_time is local clock not UTC, explains alternative for latitude/longitude/timezone use, and validates dates. Adds moderate value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns identity fields of Vedic birth chart (nakshatra, rashi, lagna, navamsa lagna) and contrasts with sibling tools like get_janam_kundali which include planet tables. Clear verb+resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'common single questions' and 'to fetch values that get_muhurta_timings accepts'. Also states when NOT to use: for planet table, yogas, dashas, and names alternatives (get_janam_kundali, get_dasha_periods).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds significant context: computation source (Swiss Ephemeris, Lahiri ayanamsa), no auth, rate limits (30 req/min/IP endpoint, 60 shared), and that dates shift with birth-time accuracy. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured, with every sentence contributing value. It covers return types, edge cases, usage, limitations, and technical details. While not overly verbose, it could be slightly tighter; however, it is very effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (no output schema, 6 parameters), the description is highly complete: it explains return structure, edge cases, usage examples, limitations, rate limits, and even suggests another tool. It provides all necessary context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description does not add new meaning to parameters beyond what the schema provides, though it mentions an edge case (present moment) relevant to usage but not to parameter values. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the Vimshottari dasha timetable, listing specific components (current periods with end dates, birth mahadasha with balance, full lifetime timeline) and distinguishes from siblings by noting that for planet placements one should call get_janam_kundali.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use the tool ('which dasha am I in', 'when does my Saturn mahadasha start') and when not to use it (for interpretation or planet placements), and provides an alternative tool (get_janam_kundali). It also clarifies the is_birth_fallback edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected. | |
| place | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), caching behavior with possible 30s recompute, rate limits, year range constraints, and city snapping. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is comprehensive but slightly lengthy. However, it is well-structured with front-loaded return information and clear sections. A minor trim could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently details return fields (eclipse type, date, times, magnitude, locally_visible flag). Also covers behavioral aspects like caching and rate limits. Complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for both parameters. Description adds meaningful extra context: default city (Delhi), snapping to 50 supported cities, year range limit (current year ±2).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns solar and lunar eclipses for a year with local visibility for a city. It distinguishes from siblings by explicitly naming get_year_events and get_panchang for other purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for eclipses and visibility questions and sutak timing; mentions alternatives for festivals (get_year_events) and daily almanac (get_panchang).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioural context beyond annotations: mentions deterministic computation, Swiss Ephemeris, rate limits, and accuracy dependency on birth-time precision. Annotations already declare readOnlyHint=true and destructiveHint=false, so the description reinforces and adds specifics without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main purpose and then details. It is comprehensive but not overly verbose; each sentence adds value. Could be slightly more concise, but structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the output contents (lagna, grahas, dasha, yogas) and notes omissions for present-moment charts. Also covers accuracy dependencies, making the tool's behavior well-understood.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a good description. The tool description does not add significant additional meaning beyond what is in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a full Vedic birth-chart summary for one person, listing specific elements (lagna, grahas, dasha, yogas). It also distinguishes from sibling tools by naming alternatives for narrower queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user wants their whole chart read' and lists four alternative sibling tools with specific narrow scopes, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| person_a | Yes | First person: gender plus birth date, birth time and place (or coordinates + timezone). | |
| person_b | Yes | Second person: same fields as person_a. Their birth place may differ from person_a's. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds significant value beyond annotations: it states '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.' This discloses rate limits, computational method, and authentication requirements. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by usage guidance, behavioral details, and rate limits. However, it is somewhat verbose and could be more concise. For example, the mention of 'no writes, no auth' is repeated in rate limit context. Overall, every sentence serves a purpose, but some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (nested objects, no output schema), the description provides a comprehensive overview of the output: eight koots with points, total, dosha, cancellation, and verdict. It also addresses the distinction from check_manglik and specifies rate limits. However, it does not describe the exact structure of the output, which could be helpful for an agent to parse the response. The absence of an output schema makes this a minor gap, but overall it is sufficient for understanding what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The tool description does not add significant new information beyond what is in the schema; it mostly reiterates that birth time is required and that place can be replaced with coordinates. This provides minimal additional value, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns classical Ashtakoot marriage compatibility, listing components like eight koots, total out of 36, dosha, cancellation, and verdict. It distinguishes itself from sibling tool get_love_compatibility, calling it 'name-numerology entertainment' and explicitly says it is not a substitute. It also clarifies that nadi/bhakoot dosha reported is chart-pair compatibility, not individual Mars dosha, directing to check_manglik for that purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this whenever real marriage matching is asked for.' It tells when not to use it: get_love_compatibility is not a substitute. It provides clear guidelines on when to use check_manglik instead for individual Mars dosha. It also specifies that both people need an exact birth time and place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name_a | Yes | 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 | Yes | Second person's name in Latin letters, e.g. "Priya". Same rules as name_a. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Descriptions adds details beyond annotations: deterministic arithmetic, no ephemeris or birth details, no writes, no auth, and rate limit of 30 req/min/IP. All consistent with readOnlyHint, idempotentHint, and destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately sized and well-structured, starting with main purpose then caveats, comparison, and technical details. Slightly verbose but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return includes a 0-100 score, short reading, and band. It covers input validation, behavior, and limitations adequately for a simple tool. Minor gap: exact JSON structure not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description mentions name reduction and digit mapping but doesn't add significant meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a name-compatibility score using Pythagorean numerology. It specifies the verb ('Returns'), the resource ('name-compatibility score'), and the method, distinguishing it from sibling tools like get_kundli_match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use only for entertainment and warns against using it for real relationship decisions, directing users to get_kundli_match for genuine matching. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mobile_number | Yes | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations: 'read-only deterministic arithmetic over a fixed number table -- no ephemeris, no network lookup, no writes, no auth, at least 30 requests/min/IP per server instance.' Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description provides concrete details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence lists outputs, second gives usage guidance and behavioral details. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without output schema, description lists all return values (digit string, total, etc.). Also covers rate limit, authentication, and distinguishes from sibling. Complete for a deterministic read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter with 100% description coverage. Description adds context: accepts various formats like +91 98765-43210, strips non-digits, must contain at least one non-zero digit. This exceeds schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns numerological reading of a phone number, listing specific outputs (digit string, total, reduced number, vibe, meaning). Distinct from sibling get_numerology by specifying it's for phone numbers only, not birth dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for 'is my phone number lucky' style questions or when choosing candidate numbers. Also states when not to use: for birth date queries, use get_numerology.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit for today's date at the given place. | |
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| janma_rashi | No | 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 entirely. | |
| janma_nakshatra | No | 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. Get the value from get_birth_details if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: read-only deterministic computation, no auth, rate limits, handling of unknown windows by including them as 'unknown' rather than omitting. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, but then includes a long list of all windows which is informative but slightly verbose. Still efficient given the detail needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: what is returned, usage, behavioral traits, rate limits, computation details, missing data handling, and sibling comparisons. No output schema, so description compensates adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% but description adds value: explains optionality behavior (omit date for today, omit janma_rashi/nakshatra removes those blocks), trade-off between place and lat/lon/timezone, and provides examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns all auspicious/inauspicious windows for one date/place. Lists specific windows. Distinguishes from siblings get_panchang and get_pancha_pakshi with explicit when-to-use guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use to CHOOSE a moment, and points to alternatives for simpler panchang or personalized timing. Also clarifies it operates on one date and one place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 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 are returned. | |
| birth_date | Yes | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, non-destructive. Description adds deterministic arithmetic, no ephemeris, no writes, no auth, rate limit 30/min/IP, and that Source line reflects this. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with outputs, then usage, then exclusions, then behavioral details. No wasted words; each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description thoroughly explains return values (mulank, bhagyank, lucky attributions, optional naam-ank). Covers constraints, rate limits, and auth. Complete for a tool with 2 params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with good descriptions. Description adds context: name is optional for Chaldean number, birth_date must be real calendar date, time/place not used. Adds extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns Vedic numerology from date of birth, listing specific outputs (mulank, bhagyank, lucky attributions) and distinguishes it from astrology and chart tools. It differentiates from sibling tools like get_janam_kundali and get_birth_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'when the user asks about their number, life path or lucky colour/day/stone.' Provides alternatives for birth chart and birth star. Also clarifies that birth time/place are not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 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). | |
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, etc. Description adds deterministic computation via Swiss Ephemeris, Lahiri ayanamsa, no writes, no auth, rate limits (30 req/min/IP + shared budget), and that window times are based on actual sunrise/sunset. This provides rich behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
5 sentences, front-loaded with main output, minimal waste. Every sentence adds value, though slightly long for a concise definition. Still well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a complex tool with many output components, the description enumerates all major outputs and adds rate limit and auth details. It is comprehensive enough for an agent to understand what the tool provides and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all 5 parameters (100% coverage). Description adds that date can be omitted for today, place is geocoded server-side, timezone must be IANA (not offset), and lat/lon required when place omitted. This adds meaningful usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the Hindu panchang for one date at one place, enumerating the five angas, lunar month, sunrise/sunset, muhurta, choghadiya, and inauspicious periods. It also distinguishes from siblings like get_muhurta_timings and get_birth_details, making the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for 'what is today's panchang / tithi / nakshatra' questions and contrasts with get_muhurta_timings for full timing surface and get_birth_details for birth star. Could be more exhaustive about when not to use, but provides solid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 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. | |
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description details computational specifics (Swiss Ephemeris, Lahiri ayanamsa), rate limits (30 req/min/IP, shared 60/min/IP), place-specificity due to sunrise/sunset, and confirms no writes or auth. This adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence is informative. It could be slightly more concise, but it is well-structured with clear sections and front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and complex functionality, the description is highly complete. It explains the output structure (yaamas, acting birds, sub-periods, strength ratings, relations) and operational details, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds value by explaining the roles (e.g., 'birth fields identify the person; date picks the day') and providing geocoding details for place. It enhances understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and clearly identifies the resource as a 'PERSONAL timing schedule under Tamil Pancha Pakshi Shastra'. It distinguishes the tool from siblings get_muhurta_timings and get_panchang by explaining this tool is personalized.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when the user wants timings tuned to THEM' and contrasts with sibling tools that give generic windows. Also mentions the two systems can disagree, providing clear guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| as_of_date | No | 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 | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly, openWorld, idempotent, non-destructive. The description adds rate limits (30/min/IP per instance, 60/min/IP shared), computation source (Swiss Ephemeris, Lahiri ayanamsa), and clarifies that dates are computed, not predicted, and no interpretation is returned. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but well-organized with front-loaded return details, followed by usage, then behavioral notes. Each sentence adds value; could be trimmed slightly but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return values, the tool's scope, rate limits, and computational nature. It covers all necessary context for an agent to understand what to expect and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description does not repeat parameter details but does not need to; the schema's parameter descriptions are already thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Sade Sati status and lists specific outputs (phase, dates, etc.). It distinguishes from the sibling tool get_transits by specifying this is Saturn-only, which helps the agent choose correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage scenarios: 'when does my sade sati start/end' and 'am I in shani sade sadi'. Also gives a clear alternative: for all grahas, use get_transits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 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. | |
| time | No | 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 full sign every two hours); the slow grahas barely move within a day. | |
| natal | No | 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. Omit and only the sky positions are returned. | |
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds: read-only deterministic computation, Swiss Ephemeris, Lahiri ayanamsa, no writes/auth, and that a call with 'natal' costs two requests. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded, but somewhat long. Every sentence is informative, so still earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description details what is returned (positions, houses, nakshatra, etc.), explains the frame, and notes rate limits. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed param descriptions. The description adds context for defaults and the effect of the 'natal' parameter on output, but the schema already does heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns planetary positions in a transit chart, with specific details like sign, degree, nakshatra, and house. It distinguishes from siblings like get_janam_kundali and get_sade_sati.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for' and 'do not scan it across many dates to find them', and names alternative tools for birth chart and dated Saturn phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | 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 if you pass latitude + longitude + timezone instead. | |
| latitude | No | 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. | |
| timezone | No | 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. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | 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 | Yes | 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 minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context: deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, no writes or auth, rate limits (30/min/IP per endpoint, 60/min/IP shared engine budget), and handling of partial results ('partial: true' on engine failure). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sentences separated by period, but somewhat lengthy. It front-loads the returned items and then adds usage and parameter details. Every sentence adds value, though a minor trim (e.g., removing 'at least' and 'plus' in rate limit sentence) could improve conciseness. Still, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema), the description covers all important aspects: what is returned (UL, A1-A12, charakarakas, karakamsha, classical texts), usage context (Jaimini vs Parashari), behavior (deterministic, read-only, rate limits), and error handling (partial results). It is fully informative for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 6 parameters described in schema). The description adds meaningful context beyond schema: explains the preferred input (place as free text), alternative lat/lon/timezone with requirements, timezone format (IANA, not offset), date format (Gregorian YYYY-MM-DD, range 1200-2400), time format (HH:MM local, required), and rationale for requiring time ('the ascendant moves about one degree every four minutes').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Jaimini layer including upapada lagna, arudha padas, charakarakas, and karakamsha lagna. It distinguishes from sibling tools like get_janam_kundali (Parashari layer) and get_kundli_match (scoring two charts). The verb 'Returns' with specific resources makes the purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use this only when Jaimini terms are asked for by name -- upapada, arudha, charakaraka, karakamsha -- or for marriage questions read the Jaimini way.' It also tells when not to use by directing to sibling tools for Parashari (get_janam_kundali) and chart matching (get_kundli_match).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected. | |
| month | No | 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 | No | 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 longitudes. | |
| category | Yes | "festival" returns every event of the year; "ekadashi", "purnima", "amavasya" and "sankranti" each narrow the list to that lunar/solar family only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds computational details (Swiss Ephemeris, cache, ~30s cold recompute), rate limits (30/min/IP per instance, 60/min/IP shared), and safety (no writes, no auth). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph but well-organized: purpose, categories, usage guidance, sibling alternatives, behavioral notes. Every sentence adds value; minor opportunity for bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers constraints (year range, city snapping, row cap), output structure (date, name, significance), and explains why city matters (longitude differences). No output schema, so description compensates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have schema descriptions (100% coverage). Description adds context: year constraints, city snapping to nearest of 50, month for pagination, and category enum meanings with examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns dated Hindu calendar events for a year at a city, lists examples (Holi, Diwali, ekadashi), and distinguishes from siblings like get_panchang and get_eclipses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('when is X this year', 'list all ekadashi dates') and when not (single day detail → get_panchang, eclipses → get_eclipses). Also mentions constraints like year range and pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.2check_kaal_sarpcheck_manglikget_birth_detailsget_dasha_periodsget_eclipsesget_janam_kundaliget_kundli_matchget_love_compatibilityget_mobile_numerologyget_muhurta_timingsget_numerologyget_pancha_pakshiget_panchangget_sade_satiget_transitsget_upapada_arudhaget_year_eventsEach tool targets a specific astrological concept or query, with detailed descriptions that clearly differentiate them. Overlap is minimal and addressed in the descriptions (e.g., get_panchang vs get_muhurta_timings).
Most tools follow a 'get_' prefix, but two use 'check_' (check_kaal_sarp, check_manglik). This is a minor deviation; the verb_noun pattern is otherwise consistent.
17 tools cover a wide range of Vedic astrology functionalities without being excessive. Each tool addresses a distinct need, from birth charts to transits to numerology.
The tool set covers core Vedic astrology operations comprehensively. Minor gaps exist (e.g., no yearly prediction tool, no gemstone recommendation), but the primary user needs are well-served.
Vedic kundli, panchang, dashas, nakshatras and KP charts for AI agents, one API key.
Professional Vedic astrology tools for AI agents via MCP.
Official Divine API MCP for Indian/Vedic Astrology: Panchang, Kundli, Dasha, KP, Lal Kitab.
Official Divine API MCP for Horoscope, Tarot, Numerology, and PDF Reports.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/puru991/kundlit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server