Core analysis

Natal Promise Analysis

analyze_natal_promise

Run Cuspal Sub Lord (CSL) promise analysis across every defined life event. The CSL is the planet ruling the sub-division at a house cusp, KP's deciding factor for whether an event is promised at all. Each row returns the verdict AND the reasoning behind it: '{ event, house, csl, chain, verdict: ACTIVE|MIXED_ACTIVE|PARTIALLY_ACTIVE|DENIED, coverage, reason, required[], covered[], missing[], signifies[], levels: {L1..L4}, starLord, starLordSignifies[], starLordDenial, motion, notes }', plus 'mixed' on a MIXED_ACTIVE row, which is undecided at the cusp (both results operate, each in the dasa of its own significators, KP Reader 4 canon p.184; whether the matter holds is a predominance call KSK makes in prose, Reader 4 canon p.110, and the engine hands it to you with the evidence) and 'bhadhaka' on a longevity-class event. **'motion' reports the CSL's retrograde, combustion and dignity state and gates nothing** — see the response's 'motion_policy'. Paged: read 'pagination.totalItems' and request further pages rather than assuming the first page is everything. Use when: starting any life-area question, and call it BEFORE any timing tool. When the user knows the birth time only roughly, pass 'birth_time_uncertainty_minutes' and each row also carries 'timeStability' ('stable' or 'changes', with 'firstChangeMinutes'), stated once in 'birth_time_window'; a verdict marked 'changes' rests on the birth time and is not settled until it is rectified. The CSL's condition on each row ('extent', 'combustStar', 'motion' with its release dates) and 'motion_policy' are a claim about the CUSP, the same on every event that shares it, and gate nothing; that claim is also a tool of its own, named in 'methodSeams': 'get_csl_condition', one row per cusp. Every row here still carries it.

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.
birth_time_uncertainty_minutes	number	No	How well the user knows the birth time, in minutes either side of the stated time. The user's own figure, never a guess; omit or 0 when the time is exact. When given, each verdict carries timeStability: whether it holds for every birth time in that window, and the nearest minute at which it changes.

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