Astro Agents - deterministic Western + Vedic astrology

Gun Milan (Ashtakoota matching)

gun_milan

Read-onlyIdempotent

Vedic astrology kundli matching (horoscope matching, marriage compatibility): 36-point Ashtakoota Gun Milan with all 8 kootas and reasons, plus dosha and Manglik checks. Varna, Vashya, Tara, Yoni, Graha Maitri, Gana, Bhakoot and Nadi scored from both Moons, each with the attributes and rule behind the score, Nadi/Bhakoot dosha flags with commonly cited cancellations, and both partners' Manglik status. Boy = person_a, girl = person_b by convention. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.25 per call via REST POST https://astro-agent.dev/v1/vedic/gun-milan (x402 or MPP); your first 3 calls are free here.

Input Schema

Name	Required	Description
`options`	No	Optional calculation settings; every default is the common Parashari convention.
`person_a`	Yes	Groom / boy (traditional convention).
`person_b`	Yes	Bride / girl.

Output Schema

Name	Required	Description
`meta`	Yes	Provenance of the result.
`result`	Yes	The calculation result.
`endpoint`	Yes	The REST route that computed it, e.g. 'western/natal'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "endpoint": {
+      "description": "The REST route that computed it, e.g. 'western/natal'.",
+      "type": "string"
+    },
+    "meta": {
+      "description": "Provenance of the result.",
+      "properties": {
+        "astronomy_library": {
+          "description": "Astronomy library and version.",
+          "type": "string"
+        },
+        "compute_ms": {
+          "description": "Computation time in milliseconds.",
+          "type": "number"
+        },
+        "computed_at": {
+          "description": "When it was computed (UTC, ISO 8601).",
+          "type": "string"
+        },
+        "deterministic": {
+          "description": "Always true: same input, same result.",
+          "type": "boolean"
+        },
+        "engine": {
+          "description": "Engine name and version.",
+          "type": "string"
+        },
+        "ephemeris": {
+          "description": "Ephemeris used (NASA/JPL DE440).",
+          "type": "string"
+        },
+        "frame": {
+          "description": "Reference frame of the positions.",
+          "type": "string"
+        },
+        "input_sha256": {
+          "description": "SHA-256 of the canonical input.",
+          "type": "string"
+        },
+        "llm_used": {
+          "description": "Always false: no language model is involved.",
+          "type": "boolean"
+        },
+        "payment": {
+          "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+          "type": "object"
+        },
+        "reproducibility": {
+          "description": "How to reproduce and check this result.",
+          "type": "string"
+        },
+        "result_sha256": {
+          "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "engine",
+        "deterministic",
+        "llm_used",
+        "input_sha256",
+        "result_sha256"
+      ],
+      "type": "object"
+    },
+    "result": {
+      "description": "The calculation result.",
+      "properties": {
+        "doshas": {
+          "description": "Matching doshas such as Bhakoot dosha, with whether each applies and is cancelled.",
+          "type": "object"
+        },
+        "kootas": {
+          "description": "The eight kootas (varna, vashya, tara, yoni, graha_maitri, gana, bhakoot, nadi), each with points scored, maximum and the reason.",
+          "type": "object"
+        },
+        "manglik": {
+          "description": "Manglik status of each person and whether the pair matches on it.",
+          "type": "object"
+        },
+        "max": {
+          "description": "Maximum possible score (36).",
+          "type": "integer"
+        },
+        "person_a": {
+          "description": "First person: subject and natal Moon (rashi, nakshatra, pada).",
+          "type": "object"
+        },
+        "person_b": {
+          "description": "Second person: subject and natal Moon (rashi, nakshatra, pada).",
+          "type": "object"
+        },
+        "settings": {
+          "description": "Settings applied, plus the Ashtakoota ruleset and convention used.",
+          "type": "object"
+        },
+        "total": {
+          "description": "Total Gun Milan score, out of 'max'.",
+          "type": "number"
+        },
+        "verdict": {
+          "description": "Plain-language reading of the total score.",
+          "type": "string"
+        },
+        "warnings": {
+          "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+          "type": "array"
+        }
+      },
+      "required": [
+        "settings",
+        "person_a",
+        "person_b",
+        "kootas",
+        "total",
+        "max",
+        "verdict",
+        "doshas",
+        "manglik"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "endpoint",
+    "result",
+    "meta"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 5, 2026

addedInput schema / properties / options / description

Added value: +"Optional calculation settings; every default is the common Parashari convention."

addedInput schema / properties / options / properties / ayanamsa / description

Added value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."

addedInput schema / properties / options / properties / include_outer_planets / description
```
Added value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."
```

First observedOct 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new operational context — determinism (JPL DE440, no LLM), a per-result meta.result_sha256 for verification, and the pricing/transport model ($0.25 per call, first 3 free) which shapes how an agent should call it. It stops short of describing latency, rate limits, or failure modes.

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?

One dense paragraph with the core capability front-loaded (matching → 8 kootas → dosha/Manglik → convention → determinism/hash → price), so an agent gets the essentials immediately. It loses a point for trailing commercial detail ('your first 3 calls are free here') and listing all eight koota names, which is more inventory than an invocation decision needs.

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?

For a two-person, deeply nested input with an output schema present, the description covers the result shape at a summary level (8 kootas with attributes/rules, dosha cancellation flags, Manglik status) and the verification hook, so nothing essential is missing. It does not need to restate return values because an output schema exists.

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

Parameters3/5

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

Schema description coverage is 100% and the nested person_a/person_b fields are already well documented, including the boy/groom and bride/girl labels, so the description's 'Boy = person_a, girl = person_b' mapping is largely redundant. The description adds no extra meaning about the options object or time-handling parameters beyond what the schema states.

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?

Names a specific verb+resource ('Vedic astrology kundli matching... 36-point Ashtakoota Gun Milan') and enumerates exactly what it computes (all 8 kootas with reasons, dosha/Manglik checks). This is specific enough that an agent can separate it from the generic kundli/natal_chart siblings without opening a schema.

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

Usage Guidelines3/5

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

Usage is implied by the domain framing ('horoscope matching, marriage compatibility') and the convention note 'Boy = person_a, girl = person_b', but there is no explicit when-to-use clause and no sibling is named as the alternative for narrower jobs (e.g. doshas, synastry). The agent must infer routing from the purpose text alone.

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

All Astro Agents - deterministic Western + Vedic astrology tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.