Transit and timing

Transit Snapshot

get_transit_analysis

Single-moment transit snapshot, checks 4 KP transit rules at one point in time, across every event the engine defines. Returns '{ queryDatetime, transitPlanets, moonTransit, rpOverlap, dashaTriggers, cuspActivations, retrogradeDelays, eventAssessments: [{ event, verdict, rulesSatisfied, housesOffered, coverage, dashaTrigger, rpStrength, rpOverlap, moonSubCovers, subLordGate, notes }], pagination, pageNote, methodSeams }'. **A transit whose star lord is retrograde in the natal chart is DELAYED, not denied.** It appears in 'retrogradeDelays' and still contributes every house it offers, so never drop it. KSK: "In Krishnamurti Padhdhati for natal horoscopes there is no place for exaltation, or debilitation or eclipse, or retrograde etc." The matter becomes due when that planet stations direct and re-crosses the degree it turned back from; report the window and the caveat together. **Read a transit on three levels, per KP Reader 5 canon p.299**: the transit STAR lord's house significations are WHAT is offered ('star_lord_significations' on each 'transitPlanets' row, and 'housesOffered' per event), the transiting planet is the SOURCE it arrives through, and the SUB lord decides WHETHER it succeeds ('sub_lord_significations', and 'subLordGate' per event). Do not read the sub lord as subject matter. 'subLordGate' reports whether the sub lords of the offering transits also signify the offered houses; it is deliberately NOT counted in 'rulesSatisfied', because the corpus states the rule but gives no threshold for scoring it, so weigh it yourself and say you did. A matter offered with 'subLordGate.supports = false' is promised but unsupported at the sub. **The event assessments are paged**, each carrying its full per-rule reasoning; this tool takes no 'event' parameter, so read 'pagination.totalItems' and page through rather than assuming page 1 holds the event you care about. Use when: 'what's happening now astrologically?'. For precise event-timing narrowing (Saturn → year, Jupiter → month, Sun → week, Moon → day) use 'get_transit_timing_hierarchy' instead. For triple-confirmation + Lagna minute-prediction use 'get_triple_transit_confirmation' and 'get_lagna_transit_windows' (both also in 'get_transit_timing_panel'). Each of its three steps is also a tool of its own, named in 'methodSeams': 'get_transit_significations' (what the transits offer now), 'get_dasha_lord_transit_triggers' (Rule 1) and 'get_transit_event_assessment' (the verdict per event, paged). Call those when a reading needs one step; this tool returns all three in one call. Books: KP Reader 5 p.299.

Parameters

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": "get_transit_analysis",
    "arguments": {
      "birth_datetime": "1992-08-14T04:32:00",
      "latitude": 6.927,
      "longitude": 79.861,
      "utc_offset_minutes": 330,
      "ayanamsa": "kp"
    }
  }
}