Vedaksha

Overview Schema Source Related Servers Discussions Admin

compute_dasha

Read-only

Generate Vedic dasha (planetary period) sequences using five classical systems, returning a JSON tree with start and end Julian Days.

Instructions

Compute Vedic dasha (planetary period) sequences. Supports five classical systems: Vimshottari, Ashtottari, Yogini (Moon-longitude based, require moon_longitude); Chara, Narayana (sign based, require BOTH lagna_sign AND graha_signs, since each sign's period length is counted to the sign its lord occupies in this chart). graha_signs takes the eight sign_index values compute_natal_chart already returns; Ketu is derived from Rahu and must not be supplied. Returns a JSON dasha tree with start/end Julian Days.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`levels`	No	Number of nested dasha levels (1–5). Ignored by Chara and Narayana.
`system`	No	Dasha system selector	Vimshottari
`birth_jd`	Yes	Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. This epoch is only added to, never converted: every returned start_jd/end_jd is on the same UT1 scale as the input.
`lagna_sign`	No	Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here.
`graha_signs`	No	Natal sign positions of the seven classical grahas plus Rahu, 0-11 each (0 = Aries), as served by compute_natal_chart's sign_index. Required for Chara, Narayana, whose period lengths are chart-dependent — each sign's duration is the count from that sign to the sign its lord actually occupies. Sign indices are used rather than longitudes: they chain directly from compute_natal_chart's sign_index with no conversion, carry no tropical-vs-sidereal ambiguity, and avoid the boundary question of a planet at exactly 30.0 degrees. Ketu is not a field: it is derived as (rahu + 6) mod 12, since the two lunar nodes are always exactly opposite.
`moon_longitude`	No	Natal Moon sidereal longitude in degrees [0, 360). Required for Vimshottari, Ashtottari, Yogini.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv8.0.1Sep 3, 2026

changedInput schema / properties / birth_jd / description

Previous value: -"Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. Dasha computation is ephemeris-free, so this epoch is carried through rather than converted: every returned start_jd/end_jd is on the same UT1 scale as the input."New value: +"Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. This epoch is only added to, never converted: every returned start_jd/end_jd is on the same UT1 scale as the input."

addedInput schema / properties / graha_signs

Added value: +{
+  "description": "Natal sign positions of the seven classical grahas plus Rahu, 0-11 each (0 = Aries), as served by compute_natal_chart's sign_index. Required for Chara, Narayana, whose period lengths are chart-dependent — each sign's duration is the count from that sign to the sign its lord actually occupies. Sign indices are used rather than longitudes: they chain directly from compute_natal_chart's sign_index with no conversion, carry no tropical-vs-sidereal ambiguity, and avoid the boundary question of a planet at exactly 30.0 degrees. Ketu is not a field: it is derived as (rahu + 6) mod 12, since the two lunar nodes are always exactly opposite.",
+  "properties": {
+    "jupiter": {
+      "description": "Jupiter's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "mars": {
+      "description": "Mars's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "mercury": {
+      "description": "Mercury's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "moon": {
+      "description": "Moon's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "rahu": {
+      "description": "Rahu's (north lunar node's) natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "saturn": {
+      "description": "Saturn's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "sun": {
+      "description": "Sun's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "venus": {
+      "description": "Venus's natal sign, 0-11 (0 = Aries).",
+      "maximum": 11,
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "sun",
+    "moon",
+    "mars",
+    "mercury",
+    "jupiter",
+    "venus",
+    "saturn",
+    "rahu"
+  ],
+  "type": "object"
+}

changedInput schema / properties / lagna_sign / description

Previous value: -"Lagna (ascendant) sign 1–12 (1 = Aries). Required for Chara, Narayana."New value: +"Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas all serve as `sign_index`, so an ascendant read from any of them passes straight through. Through v8.1.0 this one parameter was 1-indexed while every other tool was 0-indexed; that mismatch is resolved here."

changedInput schema / properties / lagna_sign / maximum
```
Previous value: -12New value: +11
```
changedInput schema / properties / lagna_sign / minimum
```
Previous value: -1New value: +0
```

addedOutput schema / description

Added value: +"Envelope depends on `system`; see the four variants below. Every period carries start_jd/end_jd on the same UT1 scale as birth_jd."

addedOutput schema / oneOf

Added value: +[
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "maha_dashas": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "initial_balance",
+      "maha_dashas"
+    ],
+    "title": "Vimshottari",
+    "type": "object"
+  },
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      },
+      "periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "starting_lord": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "starting_lord",
+      "initial_balance",
+      "periods"
+    ],
+    "title": "Ashtottari",
+    "type": "object"
+  },
+  {
+    "properties": {
+      "initial_balance": {
+        "type": "number"
+      },
+      "maha_periods": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "moon_nakshatra": {
+        "type": "string"
+      },
+      "starting_yogini_index": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "moon_nakshatra",
+      "starting_yogini_index",
+      "initial_balance",
+      "maha_periods"
+    ],
+    "title": "Yogini",
+    "type": "object"
+  },
+  {
+    "description": "Sign-based systems. Twelve single-level periods, one per rashi, in dasha order. No nakshatra or balance: these systems are anchored on the lagna and the grahas' natal signs, not the Moon.",
+    "properties": {
+      "lagna_sign": {
+        "description": "Lagna the sequence starts from, 0-11 (0 = Aries).",
+        "type": "integer"
+      },
+      "periods": {
+        "items": {
+          "properties": {
+            "duration_years": {
+              "description": "Counted from this sign to the sign its lord occupies in THIS chart, so it varies between charts.",
+              "type": "number"
+            },
+            "end_jd": {
+              "type": "number"
+            },
+            "sign_index": {
+              "type": "integer"
+            },
+            "sign_name": {
+              "type": "string"
+            },
+            "start_jd": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "sign_index",
+            "sign_name",
+            "start_jd",
+            "end_jd",
+            "duration_years"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "lagna_sign",
+      "periods"
+    ],
+    "title": "Chara / Narayana",
+    "type": "object"
+  }
+]

removedOutput schema / properties

Removed value: -{
-  "initial_balance": {
-    "description": "Fraction of the first mahadasha already elapsed at birth, in [0, 1).",
-    "type": "number"
-  },
-  "maha_dashas": {
-    "items": {
-      "properties": {
-        "duration_days": {
-          "description": "Length of the period in days.",
-          "type": "number"
-        },
-        "end_jd": {
-          "description": "End of the period as a Julian Day.",
-          "type": "number"
-        },
-        "level": {
-          "description": "Nesting depth: 1 = mahadasha, 2 = antardasha, 3 = pratyantardasha.",
-          "type": "integer"
-        },
-        "lord": {
-          "description": "Ruling graha of the period.",
-          "type": "string"
-        },
-        "start_jd": {
-          "description": "Start of the period as a Julian Day.",
-          "type": "number"
-        },
-        "sub_periods": {
-          "description": "Nested periods one level down; empty at the deepest level requested.",
-          "items": {
-            "type": "object"
-          },
-          "type": "array"
-        }
-      },
-      "required": [
-        "lord",
-        "level",
-        "start_jd",
-        "end_jd",
-        "duration_days"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "moon_nakshatra": {
-    "description": "Birth nakshatra of the Moon, which sets the starting mahadasha.",
-    "type": "string"
-  }
-}

removedOutput schema / required

Removed value: -[
-  "moon_nakshatra",
-  "initial_balance",
-  "maha_dashas"
-]

Changed1 schema field changedv8.0.0Aug 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "initial_balance": {
+      "description": "Fraction of the first mahadasha already elapsed at birth, in [0, 1).",
+      "type": "number"
+    },
+    "maha_dashas": {
+      "items": {
+        "properties": {
+          "duration_days": {
+            "description": "Length of the period in days.",
+            "type": "number"
+          },
+          "end_jd": {
+            "description": "End of the period as a Julian Day.",
+            "type": "number"
+          },
+          "level": {
+            "description": "Nesting depth: 1 = mahadasha, 2 = antardasha, 3 = pratyantardasha.",
+            "type": "integer"
+          },
+          "lord": {
+            "description": "Ruling graha of the period.",
+            "type": "string"
+          },
+          "start_jd": {
+            "description": "Start of the period as a Julian Day.",
+            "type": "number"
+          },
+          "sub_periods": {
+            "description": "Nested periods one level down; empty at the deepest level requested.",
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "lord",
+          "level",
+          "start_jd",
+          "end_jd",
+          "duration_days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "moon_nakshatra": {
+      "description": "Birth nakshatra of the Moon, which sets the starting mahadasha.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "moon_nakshatra",
+    "initial_balance",
+    "maha_dashas"
+  ],
+  "type": "object"
+}

First observedv7.0.0Aug 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already provide readOnlyHint=true, and the description goes beyond that with substantial behavioral detail: it returns a JSON dasha tree with start/end Julian Days, clarifies that the epoch is UT1 and never converted, explains Ketu is derived from Rahu, and documents a historical indexing mismatch. No contradictions 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.

Conciseness4/5

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

The description is long but dense with necessary information for a tool with two distinct parameter families and five dasha systems. It front-loads the purpose and then organizes requirements by system. A few points are repeated from the schema, but there is no filler.

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

Completeness5/5

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

Given the tool's complexity — multiple systems, conditional parameters, nested objects, and a shared convention with compute_natal_chart — the description is complete. It covers prerequisites, parameter sourcing, output shape, time-scale behavior, and edge-case conventions. The presence of an output schema also reduces the burden of explaining return structure.

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 baseline is 3, but the description adds meaningful semantics: it ties each parameter to specific dasha systems, explains the sign-to-lord period counting rule for Chara and Narayana, and warns that Ketu must not be supplied. Some detail is duplicated from the schema, but the added cross-system relationships still earn credit.

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 ('Compute Vedic dasha (planetary period) sequences') and immediately enumerates the five supported systems. It differentiates the tool from generic astrology tools by explaining that it handles multiple dasha systems with distinct input requirements.

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 gives explicit input-requirement conditions: Yogini needs moon_longitude; Chara and Narayana need both lagna_sign and graha_signs. It also tells the agent where to source these values (compute_natal_chart's sign_index). It does not explicitly contrast with sibling tools, but for this tool's own selection logic the guidance is strong.

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

Deploy Server