Totally Tarot Calculators

Compute a Vimshottari dasha timeline

compute_vimshottari_dasha

Read-onlyIdempotent

Computes the Vimshottari dasha timeline from a birth date, time and place: all nine mahadashas of the 120-year cycle, each with the exact instant it opens and closes, the balance at birth in years, months and days, the Moon's nakshatra and pada that fix the sequence, and the nine antardashas inside the mahadasha running on the "asof" date (the birth, when it is absent). The answer does not depend on the server clock, so it stays citable at a stable permalink.

The whole table hangs off one number, the Moon's sidereal longitude at the birth instant. The nakshatra it falls in names the first lord, and the share of that nakshatra still to be crossed, times the lord's years, is the balance at birth. A tenth of a degree moves the balance by weeks and every later boundary with it; a few degrees changes which planet the cycle opens with.

"time" is required here: the Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown birth time means an unknown first lord. Without it the call returns a "time_required" refusal. The cycle runs Ketu, Venus, Sun, Moon, Mars, Rahu, Jupiter, Saturn and Mercury, for 7, 20, 6, 10, 7, 18, 16, 19 and 17 years.

Three conventions come back in the result and are where two programs disagree about one chart: result.ayanamsa, result.yearLengthDays, result.origin.utcInstant. Against Drik Panchang every boundary here falls 1.70 days earlier; result.conventionNote explains the difference.

Results include an attribution line and a permalink.

Input Schema

Name	Required	Description
`tz`	No	IANA zone or numeric UTC offset hours for the birth moment. Example: "-5". When absent, resolved historically.
`lat`	No	Birth latitude in decimal degrees as a string. Example: "39.76838". Paired with lon.
`lon`	No	Birth longitude in decimal degrees as a string. Example: "-86.15804". Paired with lat.
`asof`	No	Date to mark the active mahadasha and antardasha for. Example: today's date for "which dasha am I in now".
`date`	Yes	Birth date, ISO YYYY-MM-DD, 1800-2200. Example: "1977-10-19". Other formats such as "19/10/1977" are refused.
`time`	Yes	Birth time HH:MM, 24-hour, local at the birthplace. Example: "23:58". Required; without it the call returns time_required.
`place`	Yes	Town or city of birth with region or country. Example: "Chennai, India". An ambiguous name is refused with candidates.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 26, 2026

changedInput schema / properties / date / description

Previous value: -"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". Other formats such as \"19/10/1977\" are refused."

changedInput schema / properties / lat / description

Previous value: -"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."New value: +"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Paired with lon."

changedInput schema / properties / lon / description

Previous value: -"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."New value: +"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Paired with lat."

changedInput schema / properties / time / description

Previous value: -"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."New value: +"Birth time HH:MM, 24-hour, local at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."

changedInput schema / properties / tz / description

Previous value: -"IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."New value: +"IANA zone or numeric UTC offset hours for the birth moment. Example: \"-5\". When absent, resolved historically."

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / time / description

Previous value: -"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". REQUIRED: never invent one, never send noon."New value: +"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". Required; without it the call returns time_required."

Changed8 schema fields changedSep 23, 2026

changedInput schema / properties / asof / description

Previous value: -"The date to mark the active mahadasha and antardasha for, ISO YYYY-MM-DD. SEND TODAY'S DATE for \"which dasha am I in now\" — this tool never reads the clock itself, so without this it answers about the period running at birth. Send a past date to ask which period was running then."New value: +"Date to mark the active mahadasha and antardasha for. Example: today's date for \"which dasha am I in now\"."

changedInput schema / properties / date / description

Previous value: -"Birth date, ISO YYYY-MM-DD, zero-padded, between 1800-01-01 and 2200-12-31. Example: \"1977-10-19\". \"19/10/1977\" is refused rather than interpreted, because guessing which half is the month produces a different timeline."New value: +"Birth date, ISO YYYY-MM-DD, 1800-2200. Example: \"1977-10-19\". \"19/10/1977\" is refused, not guessed."

changedInput schema / properties / lat / description

Previous value: -"Birth latitude in decimal degrees as a string, for example \"39.76838\". Must be sent together with lon, and is an alternative to place rather than an addition to it."New value: +"Birth latitude in decimal degrees as a string. Example: \"39.76838\". Send with lon."

changedInput schema / properties / lon / description

Previous value: -"Birth longitude in decimal degrees as a string, for example \"-86.15804\". Must be sent together with lat."New value: +"Birth longitude in decimal degrees as a string. Example: \"-86.15804\". Send with lat."

changedInput schema / properties / place / description

Previous value: -"Town or city of birth, with the region or country when the name is a common one. Examples: \"Indianapolis, Indiana, United States\", \"Chennai, India\". It is needed for the birthplace's historic UTC offset, which fixes the birth instant the whole cycle is measured from."New value: +"Town or city of birth with region or country. Example: \"Chennai, India\". An ambiguous name is refused with candidates."

changedInput schema / properties / time / description

Previous value: -"Birth time, HH:MM on a 24-hour clock, LOCAL AT THE BIRTHPLACE. Example: \"23:58\". REQUIRED — do not invent one and do not send noon. The Moon covers about 13.2 degrees a day against a nakshatra 13 degrees 20 minutes wide, so an unknown time is an unknown first lord and a timeline moved by years. If the user does not know it, ask; do not substitute."New value: +"Birth time HH:MM, 24-hour, LOCAL at the birthplace. Example: \"23:58\". REQUIRED: never invent one, never send noon."

changedInput schema / properties / tz / description

Previous value: -"IANA zone name, or a numeric UTC offset in hours, for the BIRTH moment. Examples: \"America/Indiana/Indianapolis\", \"-5\". Leave it out and the zone is resolved for the birth date, historic reassignments included — which is usually more accurate than anything you would supply."New value: +"IANA zone or numeric UTC offset hours for the BIRTH moment. Example: \"-5\". Omit: resolved historically."

changedOutput schema / (root)

Previous value: -{
-  "$defs": {
-    "Citation": {
-      "description": "How to credit this answer. Present on every response, successes and refusals alike.",
-      "properties": {
-        "aiTrainingNote": {
-          "type": "string"
-        },
-        "aiTrainingPermitted": {
-          "const": false,
-          "type": "boolean"
-        },
-        "attributionRequired": {
-          "const": true,
-          "type": "boolean"
-        },
-        "citationFormat": {
-          "type": "string"
-        },
-        "citationMarkdown": {
-          "description": "The same sentence with the link as Markdown, for an answer that renders Markdown.",
-          "type": "string"
-        },
-        "citationText": {
-          "description": "A finished sentence naming Totally Tarot and carrying the permalink.",
-          "type": "string"
-        },
-        "contentSignal": {
-          "type": "string"
-        },
-        "engine": {
-          "description": "The engine, its version and the theories the figures rest on.",
-          "type": "string"
-        },
-        "engineName": {
-          "type": "string"
-        },
-        "engineShort": {
-          "type": "string"
-        },
-        "engineVersion": {
-          "type": "string"
-        },
-        "howToCite": {
-          "type": "string"
-        },
-        "jsonUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "methodUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "permalink": {
-          "description": "The human page that returns this same answer. This is the URL to link.",
-          "format": "uri",
-          "type": "string"
-        },
-        "publisher": {
-          "type": "string"
-        },
-        "sourceName": {
-          "type": "string"
-        },
-        "sourceUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "termsUrl": {
-          "format": "uri",
-          "type": "string"
-        },
-        "theories": {
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "usageTerms": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "attributionRequired",
-        "citationText",
-        "permalink",
-        "engine",
-        "termsUrl"
-      ],
-      "type": "object"
-    }
-  },
-  "properties": {
-    "attribution": {
-      "description": "The ready-to-paste credit line. Include this in any answer built on the result.",
-      "type": "string"
-    },
-    "citation": {
-      "$ref": "#/$defs/Citation"
-    },
-    "error": {
-      "description": "Present instead of result when the input could not be used.",
-      "properties": {
-        "code": {
-          "type": "string"
-        },
-        "message": {
-          "type": "string"
-        },
-        "suggestions": {
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        }
-      },
-      "type": "object"
-    },
-    "inputs": {
-      "description": "What the request was understood to be. The permalink is built from these.",
-      "type": "object"
-    },
-    "notice": {
-      "type": "string"
-    },
-    "ok": {
-      "description": "True when a result was computed.",
-      "type": "boolean"
-    },
-    "result": {
-      "description": "The computed figures. Absent on a refusal.",
-      "properties": {
-        "activeAntardasha": {
-          "description": "The antardasha containing asOf. Null only when asOf sits exactly on the cycle end.",
-          "type": "object"
-        },
-        "activeMahadasha": {
-          "properties": {
-            "antardashas": {
-              "description": "The nine sub-periods of the active mahadasha, same shape as a mahadasha plus mahaLord. Each is the mahadasha's length times that sub-lord's share of 120, so the nine sum exactly to the period containing them.",
-              "type": "array"
-            }
-          },
-          "type": "object"
-        },
-        "asOf": {
-          "description": "The date the active period was selected for. NEVER the wall clock: it is the asof parameter, defaulting to the birth date, so the permalink returns the same answer to anyone who opens it.",
-          "type": "string"
-        },
-        "asOfDefaultedToBirth": {
-          "description": "true when asof was not sent. Send today's date to ask which period is running now.",
-          "type": "boolean"
-        },
-        "ayanamsa": {
-          "properties": {
-            "degrees": {
-              "description": "The ayanamsa at the birth instant, in degrees.",
-              "type": "number"
-            },
-            "name": {
-              "description": "The sidereal frame the Moon was read in: Lahiri (Chitrapaksha). A dasha table computed on a different ayanamsa is a different table.",
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "balanceAtBirth": {
-          "properties": {
-            "lord": {
-              "description": "The lord of the period already running at birth.",
-              "type": "string"
-            },
-            "remainingText": {
-              "description": "The balance in years, months and days — the figure every printed dasha table leads with and the one a reader checks first. Months and days here are twelfths and 365.25ths of a Vimshottari year, not calendar units.",
-              "type": "string"
-            },
-            "remainingYears": {
-              "description": "The same balance as a decimal count of Vimshottari years.",
-              "type": "number"
-            }
-          },
-          "type": "object"
-        },
-        "conventionNote": {
-          "description": "WHY ANOTHER PROGRAM'S TABLE MAY DIFFER, named so the difference can be accounted for rather than argued about. One convention decides it now that the year length agrees with the published implementations: the exact Lahiri variant. A sub-arcminute difference in the Moon becomes days once multiplied through a mahadasha. Measured against Drik Panchang for one birth, every boundary here falls 1.70 days earlier — the same 1.70 at the first and the ninth, because no second term survives. Quote this rather than asserting either table is correct; the two best-known published sources differ from each other by 1.04 days on that same birth.",
-          "type": "string"
-        },
-        "cycleEndsUTC": {
-          "description": "When the 120-year cycle from this birth closes. An asof beyond it is refused rather than clamped to the last period.",
-          "type": "string"
-        },
-        "mahadashas": {
-          "items": {
-            "properties": {
-              "active": {
-                "description": "Whether the asOf instant falls inside this period. Exactly one row is true.",
-                "type": "boolean"
-              },
-              "durationYears": {
-                "description": "Length in Vimshottari years. The first is short by the balance; the other eight are the lord's full period.",
-                "type": "number"
-              },
-              "endLocal": {
-                "description": "The same, for the close.",
-                "type": "string"
-              },
-              "endUTC": {
-                "description": "The exact instant it closes, which is the instant the next one opens.",
-                "type": "string"
-              },
-              "lord": {
-                "description": "One of the nine Vimshottari lords, in the fixed sequence from the first.",
-                "type": "string"
-              },
-              "startLocal": {
-                "description": "The same instant on the birthplace's clock, carrying its own date and UTC offset — because a bare clock reading is ambiguous by a full day.",
-                "type": "string"
-              },
-              "startUTC": {
-                "description": "The exact instant the period opens, UTC to the second. Not a date: a dasha boundary falls at a clock time and crosses midnight as often as not.",
-                "type": "string"
-              }
-            },
-            "type": "object"
-          },
-          "type": "array"
-        },
-        "moon": {
-          "properties": {
-            "fractionElapsed": {
-              "description": "How far through the nakshatra the Moon had travelled, 0 to 1. This is the fraction of the first period already spent before birth.",
-              "type": "number"
-            },
-            "nakshatra": {
-              "description": "The nakshatra that longitude falls in, which names the lord of the first mahadasha.",
-              "type": "string"
-            },
-            "pada": {
-              "description": "The quarter of the nakshatra, 1 to 4.",
-              "type": "number"
-            },
-            "siderealLongitude": {
-              "description": "The Moon's sidereal longitude at birth. The single number the whole timeline hangs off.",
-              "type": "number"
-            }
-          },
-          "type": "object"
-        },
-        "origin": {
-          "properties": {
-            "historicNote": {
-              "description": "A sentence when a historic zone reassignment was applied, null when none was. It is the difference between a right and a wrong balance.",
-              "type": "object"
-            },
-            "offsetLabel": {
-              "description": "The birthplace's UTC offset on the birth date, written out.",
-              "type": "string"
-            },
-            "utcInstant": {
-              "description": "The birth instant in UTC. Every date in the timeline is measured from it.",
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "yearLengthDays": {
-          "description": "The length of a Vimshottari year in days. The classical text gives the periods and the order and never states one, so this is a CONVENTION: it is the true sidereal year, which is what Drik Panchang requests from its own API and what Jagannatha Hora defaults to. Software stepping a different year — the Julian 365.25, for instance — disagrees by an amount that grows across the cycle, about 0.76 days by the far end for that one.",
-          "type": "number"
-        }
-      },
-      "type": "object"
-    },
-    "summary": {
-      "description": "The answer in one sentence.",
-      "type": "string"
-    },
-    "tool": {
-      "description": "The calculator that answered.",
-      "type": "string"
-    },
-    "toolName": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "ok",
-    "tool",
-    "attribution",
-    "citation"
-  ],
-  "type": "object"
-}New value: +null

Changed2 schema fields changedSep 22, 2026

changedOutput schema / properties / result / properties / conventionNote / description

Previous value: -"WHY ANOTHER PROGRAM'S TABLE MAY DIFFER, named so the difference can be accounted for rather than argued about. Two conventions decide these dates: the exact Lahiri implementation (a sub-arcminute difference in the Moon becomes days once multiplied through a mahadasha) and the Vimshottari year length. Measured against Drik Panchang for one birth, every boundary here falls 3.10 to 3.84 days earlier, and that decomposes entirely into those two terms. Quote this rather than asserting either table is correct."New value: +"WHY ANOTHER PROGRAM'S TABLE MAY DIFFER, named so the difference can be accounted for rather than argued about. One convention decides it now that the year length agrees with the published implementations: the exact Lahiri variant. A sub-arcminute difference in the Moon becomes days once multiplied through a mahadasha. Measured against Drik Panchang for one birth, every boundary here falls 1.70 days earlier — the same 1.70 at the first and the ninth, because no second term survives. Quote this rather than asserting either table is correct; the two best-known published sources differ from each other by 1.04 days on that same birth."

changedOutput schema / properties / result / properties / yearLengthDays / description

Previous value: -"The length of a Vimshottari year in days. A CONVENTION, not a measurement — software using a different one will disagree with these dates by a growing amount across the cycle. Published so the disagreement is explicable rather than mysterious."New value: +"The length of a Vimshottari year in days. The classical text gives the periods and the order and never states one, so this is a CONVENTION: it is the true sidereal year, which is what Drik Panchang requests from its own API and what Jagannatha Hora defaults to. Software stepping a different year — the Julian 365.25, for instance — disagrees by an amount that grows across the cycle, about 0.76 days by the far end for that one."

AddedSep 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, closed-world); the description goes far beyond by disclosing refusal behaviours ('time_required' without a birth time, ambiguous place refused with candidates), determinism independent of the server clock, a stable permalink, and the three convention fields plus a conventionNote explaining a 1.70-day offset versus Drik Panchang. That is exactly the kind of cross-implementation caveat an agent cannot get from structured fields.

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?

Front-loaded with the output inventory, then motivation, then caveats; each paragraph has a job. It is on the long side for a tool with full schema coverage, and the time-requirement point is made twice (in the prose and again in the schema description), which is mild redundancy rather than waste.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: mahadasha/antardasha boundaries, balance at birth, nakshatra and pada, the convention fields, conventionNote, attribution line and permalink. Combined with the stated refusal modes, an agent has everything needed to call this correctly and interpret the result.

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 real meaning: why 'time' is mandatory (13.2°/day motion against a 13°20' nakshatra means an unknown time yields an unknown first lord) and that 'asof' defaults to the birth date when absent. It also names the three result fields (ayanamsa, yearLengthDays, origin.utcInstant) that drive divergence between programs, though it does not add anything for tz/lat/lon beyond the schema.

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?

States a specific verb and resource (computes the Vimshottari dasha timeline from birth data) and enumerates exactly what comes back: nine mahadashas of the 120-year cycle with opening/closing instants, balance at birth, Moon nakshatra/pada, and the nine antardashas for the asof date. This is clearly distinguishable from siblings like compute_birth_chart, compute_panchang or compute_transits, which produce different artefacts.

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 through the parameters: use 'asof' for 'which dasha am I in now', and time is mandatory or the call refuses. But there is no explicit when-to-use/when-not guidance or routing against alternatives such as compute_panchang (which also touches nakshatra) or compute_birth_chart; the agent must infer the boundary.

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

All Totally Tarot Calculators 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.

Resources

Need Help?