Skip to main content
Glama

Vedic Astrology and Kundli MCP Server by RoxyAPI

Calculate ten porutham match - Dashakoot South Indian Kundli Matching API

post_vedic_astrology_compatibility_dashakoot
Read-only

Calculate the South Indian ten porutham marriage match (Dashakoot, also called Dasa Porutham) for two birth records. Returns a pass or fail on each of Dina, Gana, Mahendra, Stree Deergha, Yoni, Rasi, Rasyadhipati, Vasya, Rajju and Vedha, a total out of ten, and Rajju and Vedha as explicit hard vetoes that disqualify a match whatever the rest of the sheet reads. This is a different system from the 36 point Ashtakoot Gun Milan on POST /vedic-astrology/compatibility and the two are never reconciled, so a Tamil, Malayalam or Telugu matrimonial desk can read the sheet it actually uses. Direction matters: person1 is the groom and person2 is the bride, because five of the ten poruthams count from the bride birth star to the groom birth star.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoResponse language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.en
compactNoSet true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
person1YesBirth data of the GROOM. Direction is load bearing in this system: Dina, Mahendra, Stree Deergha, Rasi and Vasya all count from the bride toward the groom, so sending the two people the wrong way round returns a different and wrong sheet without any error.
person2YesBirth data of the BRIDE. Five of the ten poruthams count FROM this birth star, so this field is not interchangeable with person1. Date, time and location determine the Moon nakshatra and Moon rashi every porutham reads.
ayanamsaNoSidereal frame (ayanamsa) the chart is cast in. "lahiri" is Lahiri/Chitrapaksha, the traditional Vedic standard used by most software, and is the default. "raman" is the B.V. Raman ayanamsa from Hindu Predictive Astrology, about 1.45 degrees below Lahiri. "kp-newcomb" and "kp-old" are the two Krishnamurti Paddhati frames. "custom" takes your own value in degrees via ayanamsaValue, for reconciling exactly against a specific reference program. The frame rotates the whole zodiac, so a graha sitting within 1.45 degrees of a boundary can change rashi or nakshatra when you switch: pick the one your reference software uses and keep it.lahiri
ayanamsaValueNoCustom ayanamsa value in degrees. When provided, overrides the computed ayanamsa from the selected type. Use for testing with specific ayanamsa values or matching a particular reference source.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
frameYes
rajjuYes
totalYes
vedhaYes
verdictYes
maxTotalYes
breakdownYes
recommendationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / person1 / properties / timezone / description
      Previous value: -"Timezone: IANA name (e.g. \"America/New_York\", \"Europe/London\") OR decimal hours from UTC (e.g. -5 for EST, 1 for CET). IANA strings are resolved to the offset in force at the given date and time, so you can pass `cities[0].timezone` from /location/search directly. Defaults to 5.5."New value: +"Timezone: an IANA name (e.g. \"America/New_York\", \"Europe/London\", or `cities[0].timezone` from /location/search) or decimal hours from UTC (e.g. -5 for EST, 5.5 for IST). An IANA name is resolved to the offset in force at the given date and time. Defaults to 5.5."
    • changedInput schema / properties / person2 / properties / timezone / description
      Previous value: -"Timezone: IANA name (e.g. \"America/New_York\", \"Europe/London\") OR decimal hours from UTC (e.g. -5 for EST, 1 for CET). IANA strings are resolved to the offset in force at the given date and time, so you can pass `cities[0].timezone` from /location/search directly. Defaults to 5.5."New value: +"Timezone: an IANA name (e.g. \"America/New_York\", \"Europe/London\", or `cities[0].timezone` from /location/search) or decimal hours from UTC (e.g. -5 for EST, 5.5 for IST). An IANA name is resolved to the offset in force at the given date and time. Defaults to 5.5."
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds substantial behavioral context on top: Rajju and Vedha act as 'explicit hard vetoes that disqualify a match whatever the rest of the sheet reads', and five of the ten poruthams are direction-sensitive counting from bride to groom. These are non-obvious behaviors an agent must know to interpret results correctly, and they go well beyond what the annotations state.

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

Conciseness4/5

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

Roughly three dense sentences, each earning its place: the calculation and return shape, the sibling-system distinction with use context, and the direction warning. It is front-loaded with the verb and resource, and lists the ten poruthams compactly. Slightly long, but the complexity (ten named components, veto rules, Ayanamsa context) justifies the length; no filler or tautology.

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

Completeness4/5

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

Given an output schema (returns covered), 100% schema coverage on 6 parameters including nested objects, and annotations covering the safety profile, the description is nearly complete. It supplies the essential missing context: the system identity, the sibling distinction, the veto semantics, and the groom/bride ordering constraint. It could add failure or boundary behavior, but nothing an agent needs to invoke this correctly is absent.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents every parameter thoroughly, including person1=GROOM and person2=BRIDE. The description adds value by explaining WHY the direction is load-bearing ('five of the ten poruthams count from the bride birth star to the groom birth star'), reinforcing the role semantics beyond what parameter names alone convey. This is a meaningful increment over the schema baseline of 3.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Calculate the South Indian ten porutham marriage match (Dashakoot...)'. It enumerates all ten poruthams, states the return shape (pass/fail each, total out of ten, vetoes), and explicitly disambiguates itself from the sibling 'POST /vedic-astrology/compatibility' 36-point Ashtakoot system. An agent can tell exactly what this tool computes and how it differs from its nearest sibling without opening either schema.

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

Usage Guidelines4/5

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

The description names the alternative ('the 36 point Ashtakoot Gun Milan on POST /vedic-astrology/compatibility'), states that the two are never reconciled, and gives a concrete audience ('a Tamil, Malayalam or Telugu matrimonial desk can read the sheet it actually uses'). It also warns that direction matters and person1/person2 are not interchangeable. The when-to-use is clear, though the when-not-to-use is conveyed by contrast rather than an explicit routing instruction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources