Advanced techniques
Triple-Dasha Overlap Workflow (Vimshottari, Yogini, Chara)
run_triple_dasha_consensus
[Cross-system: KP Vimshottari, Parashari Yogini, Jaimini Chara, side by side] Where the DATE RANGES of three dasha systems overlap. Only the Vimshottari input is chosen for the event (the MD-AD periods whose lords signify its required houses, ranked from query_date); the Yogini and Chara inputs are the current and next period whatever the event, and Yogini starts from the Moon's nakshatra exactly as Vimshottari does, so the three are NOT independent witnesses. 'convergenceLevel' counts overlaps (STRONG = a triple overlap; PARTIAL = two or more Vimshottari-Yogini overlaps; WEAK = one; DIVERGENT = none), a Lumin convention labelled by 'scoreProvenance', and 'baseRate' gives how often each level occurs for this event over a fixed 200-chart sample: STRONG is met by most charts whatever the event (F089), so read the level against it and never as confirmation or confidence. 'inputs[]' names each system with its selection rule and method note; 'independence' names what they share. Named after K.N. Rao's practice of reading an event in more than one dasha; his convention reads the Chara dasha for the matter, which this tool does not. The Chara witness is K. N. Rao's Chara dasha by default ('charaLineage' names it; 'chara_lineage' picks another); other lineages can name a different sign. Returns '{ vimshottariWindows[], yoginiCurrent, yoginiNext, charaCurrent, charaNext, charaLineage, convergenceWindows: [{ startDate, endDate, systemsAgreeing: 2|3 }], convergenceLevel, scoreProvenance, baseRate, inputs[], independence, summary }'. For timing compared by each system's own procedure, get_paradigm_panel with target_year.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
| birth_datetime | string | Yes | Birth date and time in ISO 8601 format (e.g., "1990-05-15T14:30:00"). |
| latitude | number | Yes | Birth location latitude. Range: -90 to 90. |
| longitude | number | Yes | Birth location longitude. Range: -180 to 180. |
| utc_offset_minutes | number | Yes | UTC offset in minutes (e.g., 330 for IST, -300 for EST). |
| ayanamsa | enum: kp | kp_new | lahiri | raman | true_chitra | khullar | No | Ayanamsa system. Defaults to kp. |
| chara_lineage | enum: knRao | pvrSjc | raghavaBhattaRangacharya | legacy | No | Which Chara dasha lineage is the third witness (default knRao). |
| event | string | No | Event to time (e.g. 'Marriage'). Default: Marriage. |
| query_date | string | No | ISO date (default: now). Send a zone (Z, or +hh:mm as in 2026-10-20T10:30:00+05:30). A value without a zone is read as UTC, never as local time, and a date alone is midnight UTC. This is a different moment from judgement_datetime, which is a local wall clock sent with its own offset. |
| top_windows | number | No | Top N Vimshottari windows to check (default: 5). |
Example call
Send the request as a standard MCP tools/call:
POST https://mcp.lumin.guru/mcp
Authorization: Bearer mcp_yourkey...
Accept: application/json, text/event-stream
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "run_triple_dasha_consensus",
"arguments": {
"birth_datetime": "1992-08-14T04:32:00",
"latitude": 6.927,
"longitude": 79.861,
"utc_offset_minutes": 330,
"ayanamsa": "kp"
}
}
}Birth data
This tool requires birth data on every call. The MCP server is stateless, so calling set_birth_profile first validates the data and returns the reading plan, but it does not store anything. Repeat the same five fields here.