Advanced techniques
Birth-Time Spread (which sub lords and verdicts move within the stated uncertainty)
get_birth_time_spread
[KP] Rebuilds the chart across the birth-time uncertainty the user states and reports exactly which cusp sub lords change, at which minute, and which promise verdicts change between which values. Use it BEFORE stating any verdict whenever the user knows their birth time only roughly ('about 7:20', 'to the nearest five minutes'): measured over 48 charts ('scripts/bp022-birth-time-spread.ts'), at plus or minus 5 minutes 72.9% of promise verdicts change inside the window and 51.3% cross DENIED. Every instant at which a cusp or planet changes sign, star, sub or house, or a node gains or loses a conjunction or aspect, is solved to the second, and the same gate analyze_natal_promise runs is re-run between those instants (never on a grid). Returns per cusp the stated lords, every change with its minute and 'subLordHoldsOver' (the stretch of birth times over which the stated sub lord holds); per planet its house and lord changes; 'nodeContactChanges'; and per event 'timeStability' ('stable' or 'changes'), 'verdictsInWindow', 'crossesDenied', 'statedVerdictHoldsOver', 'firstChangeMinutes' (the nearest minute, signed, at which the verdict becomes something else), 'intervals' with the deciding CSL, and 'changes' each naming its 'causes'. READ 'summary.eventsStable' FIRST: those verdicts rest on nothing the uncertainty moves and can be stated outright. A verdict marked 'changes' is not settled until the time is rectified (rectify_birth_time, rectify_by_event_ruling_planets): give the reading on each side of the minute that separates them, or rectify first. The source is Astro Secrets canon p.180 (a later author, not KSK): 'in case birth time given is wrong, it has to be rectified. Otherwise cuspal sublords and planet sublords will vary'. The window is the user's own figure: never invent one, and ask when it is unknown. Nothing is scored, ranked or weighed and no minute is picked. **'cusps' and 'events' are paged together**: page N carries the Nth page of each, cut to its own row weight, and a list that ends sooner is empty on the pages after its last (the page note says which); 'planets', 'nodeContactChanges' and 'summary' repeat whole on every page.
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 | Yes | How well the user knows the birth time, in minutes either side of the stated time (5 means the true time lies between 5 minutes earlier and 5 minutes later). REQUIRED and always the user's own figure: never guess it. Past 60 minutes the question is which chart this is, which the rectification tools answer. |
| life_events | unknown | No | Event names to spread, as analyze_natal_promise names them (e.g. "Marriage"). Omit for every defined event. |
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_birth_time_spread",
"arguments": {
"birth_datetime": "1992-08-14T04:32:00",
"latitude": 6.927,
"longitude": 79.861,
"utc_offset_minutes": 330,
"ayanamsa": "kp",
"birth_time_uncertainty_minutes": 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.