Vedic astrology from a real ephemeris: birth chart, life-event timing and Kundli matching.
Scored across 3 tools
Each tool targets a clearly distinct purpose: read_kundli reads a single birth chart, match_kundli compares two people for compatibility, and life_timing answers 'when/will' questions. The descriptions name explicit use-phrases that keep the boundaries sharp, so an agent can route reliably.
match_kundli and read_kundli follow a clean verb_noun convention, but life_timing breaks the pattern with a noun_noun form and is the odd one out. Minor deviation, still readable and consistent in snake_case.
Three tools is on the lean side but each bundles a large feature set (verdicts, timing windows, full koota breakdown), so nothing feels redundant or filler. Reasonable for a focused niche domain, if slightly under what a full astrology suite might offer.
Core Vedic workflows are covered: chart reading, compatibility, and timing with remedies. Minor gaps exist (standalone panchang/muhurta or dosha-only queries), but the primary agent journeys have no dead ends.
Times one life question from the Vedic chart: marriage, money (career and income), abroad (travel and settling overseas), love, job (job change), sade-sati (Saturn phase and when it ends) or year-ahead. Returns a verdict, the nearest strong window to the month, the strongest month, the planet reason, a simple remedy and a 12-month tone bar. Use for "when will I…" or "will I…" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | First name, if the person gave one. | |
| topic | Yes | Which life question to time. | |
| gender | No | Only if the person said it; it refines marriage timing. | |
| birth_date | Yes | Date of birth as YYYY-MM-DD. | |
| birth_time | No | Time of birth as 24-hour HH:MM, local time at the birth place. Leave out if unknown (the rising sign and houses are then skipped). | |
| birth_place | Yes | Town or city of birth with country, e.g. "Hyderabad, India". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description goes beyond them by spelling out the return contents (verdict, near window, strongest month, planet reason, remedy, 12-month tone bar), which is valuable given there is no output schema. It does not discuss determinism of results or cost, hence not a 5.
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, front-loaded with what gets timed, then returns, then the usage trigger. The middle clause packs a long return list and topic glosses, which is dense but every element carries information for the caller, so there is little waste.
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?
For a 6-parameter tool with no output schema, the description covers purpose, topic vocabulary, expected outputs and the trigger phrasing, so an agent has enough to invoke it correctly. Minor gaps remain (no explicit guidance on how birth_time absence affects results beyond the schema's own note, no exclusions), keeping it from a 5.
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 baseline is 3, but the description adds real meaning to several enum values the schema lists only by name: 'money (career and income)', 'abroad (travel and settling overseas)', 'job (job change)', and 'sade-sati (Saturn phase and when it ends)'. That glossing helps an agent pick the right topic, which is the one call that most affects the result, though the remaining params (name, gender, birth_*) are left to 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 states a specific verb+resource ('Times one life question from the Vedic chart') and enumerates the exact topics it handles, so its scope is unambiguous. It never names the siblings match_kundli or read_kundli to draw the boundary, so it falls just short of the top mark, but the distinct 'timing' purpose is easy to separate from chart-reading or matching tools.
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 gives an explicit trigger: 'Use for "when will I…" or "will I…" questions,' which cleanly maps user phrasing onto this tool. It offers no when-not conditions and no named alternative for adjacent cases (e.g. reading a chart vs timing a question), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marriage compatibility of two people from their birth details: Ashtakoot Guna Milan score out of 36 with all 8 kootas, Nadi and Bhakoot dosha, and each person's Mangal (Manglik) dosha with cancellations. Use for "match me with my partner", "kundli milan", "are we compatible".
| Name | Required | Description | Default |
|---|---|---|---|
| person_a | Yes | The person asking (usually "me"). | |
| person_b | Yes | Their partner or prospective match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), lowering the bar. The description adds useful output-shape context — the specific score, kootas and dosha reporting — which compensates for the missing output schema.
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 the core purpose and output summary, then the trigger phrases. One dense sentence plus a short usage list; every element earns its place, though the output enumeration is fairly packed.
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 nested two-person input, the description compensates well by enumerating the returned artifacts (36-point score, 8 kootas, doshas, cancellations). An agent knows what it will get back and what inputs are required.
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% and both parameters (person_a, person_b) are fully documented with nested field descriptions, so the schema carries the burden. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 correct.
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?
States a specific verb and resource — marriage compatibility of two people from birth details — and enumerates the exact outputs (Ashtakoot Guna Milan out of 36, 8 kootas, Nadi/Bhakoot dosha, Mangal dosha). It is clearly distinct from read_kundli and life_timing, though it does not name those siblings explicitly.
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 concrete trigger phrases ('match me with my partner', 'kundli milan', 'are we compatible') that map natural user requests to this tool. No exclusions or explicit when-not-to-use guidance, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vedic birth chart (Kundli) at a glance from date, time and place of birth: rising sign (lagna), Moon sign (rashi), nakshatra, the planet period (Vimshottari dasha) running now, and where each planet sits. Use when someone asks about their chart, rashi, nakshatra or dasha.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | First name, if the person gave one. | |
| birth_date | Yes | Date of birth as YYYY-MM-DD. | |
| birth_time | No | Time of birth as 24-hour HH:MM, local time at the birth place. Leave out if unknown (the rising sign and houses are then skipped). | |
| birth_place | Yes | Town or city of birth with country, e.g. "Hyderabad, India". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds almost nothing behavioral beyond that; the notable degradation rule (skipping lagna/houses when birth_time is absent) lives in the schema parameter description, not here.
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, zero filler, and the content inventory is front-loaded before the usage trigger. Every clause earns its place.
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?
With no output schema, the description correctly enumerates the returned fields, which is what an agent needs to know the result is worth calling for. It is nearly complete; the only gap is not clarifying its relationship to the sibling tools.
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 four parameters including the omission semantics for birth_time. The description does not add format or constraint detail beyond what the schema provides, making the baseline 3 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?
Specific verb+resource ('Vedic birth chart (Kundli)') with an explicit inventory of what it returns: lagna, rashi, nakshatra, Vimshottari dasha, planetary positions. It does not name or distinguish itself from the siblings life_timing or match_kundli, so an agent must infer the boundary.
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?
Gives a clear trigger condition: 'Use when someone asks about their chart, rashi, nakshatra or dasha.' That covers the common invocation context, but there is no when-not guidance and no routing to life_timing or match_kundli, which are the obvious adjacent tools.
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.
life_timingmatch_kundliread_kundliEphemeris natal & mundane charts, Vimshottari Dasha, transit horoscopes, Horas, and Vedic yogas.
30 Vedic Jyotish tools: natal charts, dashas, yogas, nakshatras. Swiss Ephemeris.
Vedic kundli, daily sky, kundli milan, sade sati and mangal dosha from birth details.
Vedic astrology (Jyotish): birth charts, divisional charts, dashas, yogas, transits, panchang
Add one secure layer between your agents and this server.
