Chart and reference

Event Dasha Periods

get_event_dasha

Find which Vimshottari dasha periods reach a specific life event. Lists EVERY antardasha under a mahadasha lord that signifies a required house, each with its own 'coverage' (the percent of the event's required houses the MD and AD lords together signify), 'matchingHouses[]' and 'missingHouses[]', so a period that reaches one house of a three house group is a row with a low coverage, not an omission; the mahadasha lords that signify none are named in 'unlistedMahadashas'. 'confidence' (Strong/Moderate/Weak) is a Lumin cut on coverage, labelled in 'scoreProvenance'. Current periods come first, then future, then past, by coverage within each, a presentation order and not a KP ranking. Returns '{ event, eventLabel, requiredHouses[], totalMatchingPeriods, periods: [{ mahadasha, antardasha, startDate, endDate, coverage, matchingHouses[], missingHouses[], confidence, isCurrent, isFuture }], unlistedMahadashas[], scoreProvenance, queryDateUsed, eventResolution }'. If 'event' is omitted, the engine derives the most active event from the running MD+AD signification with RP tie-break and says which in 'eventResolution', a field a named 'event' does not produce. **Paged by period** when the list does not fit one response (up to 81 rows): 'unlistedMahadashas', 'totalMatchingPeriods', 'scoreProvenance', 'queryDateUsed' and 'eventResolution' (when present) ride on every page, 'pagination' and 'pageNote' say how many pages remain, and nothing is dropped. For 3-level (MD+AD+PD) timing + RP filtering + transit hierarchy, prefer 'find_event_timing_v2'.

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.
event	event name	No	Event to analyze dasha periods for. If omitted, the engine derives the most active event from the running MD+AD lord's signification with Ruling Planets tie-break, and returns it in the eventResolution field.
query_date	string	No	The moment the periods are judged from (default: now): which period is current, which are still to come, and their order. 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.

Example call

Send the request as a standard MCP tools/call:

http

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": "get_event_dasha",
    "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.