Advanced techniques
Arrival Horary: will the awaited come, and when?
get_arrival_timing
KP horary for "when will X get here" — an awaited person, a spouse returning, a missing person coming home, a letter, or a late train or flight. Takes a question_number (1-249) and a 'subject'. **Two gates, and they do not commute:** the chart must PROMISE arrival before any timing is attempted, and a 'REFUSED' verdict is a complete answer that deliberately carries no window — no amount of favourable timing forces an event the deciding sub lord denies. The rule reads the STAR LORD OF THE DECIDING CUSP'S SUB LORD, not the sub lord itself. Per subject the deciding cusp is: person → 7th, spouse → 11th (joining 11-7-6, separation 12-7-6), missing_person → 11th (promise 2-4-6-11, timed by 2-8-11), letter → 3rd (3 and 11), conveyance → 4th (movable sign reaches soon, fixed a long delay, common a delay). Core rule: the star lord signifying 3/5/9 with 7 or 11 means the person arrives early; 5/7/11 means later but it must signify 3 and 9 without fail; 4/8/10/12 means "the expected person changes his mind and stays back". **Arrival elects on 3-9-11, never the 3-9-12 of foreign settlement** — the 12th pulls toward staying away, so it sits in the refusal set. Returns each house test with its own citation, the obstruction reading for any 6/8/12 link, a retrograde flag (read as DELAY, never denial), and a timing 'scale' from the 11th cusp sub lord's sign modality that names which hand of the clock to move (Ascendant for hours, Moon for days, Sun for longer). The scale is a scale, not a timestamp. Contested points travel in 'provenance.contestedPoints': retrogression in an arrival query is read the opposite way by some practitioners, and this tool does not rotate the chart to the awaited person's house. UNKNOWN means significators were unavailable, so report that there is no verdict. For a lost object or a stolen article use 'get_lost_or_missing' instead; a merchandise parcel is a recovery question (2-6-11), not a letter. Books: KP Reader VI (Horary Astrology), Astrology & Athrishta, KP Ezine case studies.
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. |
| question_number | number | Yes | Querent's KP question number (1-249) |
| subject | unknown | No | What is awaited. Routes to a different sourced rule and a different deciding cusp. |
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_arrival_timing",
"arguments": {
"birth_datetime": "1992-08-14T04:32:00",
"latitude": 6.927,
"longitude": 79.861,
"utc_offset_minutes": 330,
"ayanamsa": "kp",
"question_number": 0
}
}
}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.