Chart and reference
Retrograde verdicts: per-planet delivery, Neecha Bhanga, signification shift [Parashari]
get_retrograde_verdicts
Parashari, not KP, and unsourced: the module's header says its verdict and signification-adjustment layers rest on no text on disk, and KP's own retrograde doctrine (binary, a timing rule, gating no promise) is 'get_retrograde_panel' and its steps. For each of Mars, Mercury, Jupiter, Venus and Saturn that is retrograde or within 0.05 degrees a day of a station (the Sun and Moon never retrograde; the nodes are skipped), from the positions and the Placidus cusps: the station status (STATION_RETROGRADE, STATION_DIRECT, NORMAL), the occupied house (also 'secondary_results_house') and the primary results house (the 7th from it), the sign, and dignity, combustion and Neecha Bhanga, all three REPORTED and deciding nothing ('dignity_provenance', F066); then one 'verdict' by the first rule that applies, OBSTRUCTED (in the 6th, 8th or 12th), ONSET_DELAY or RESUMING (stationing retrograde or direct), STRONG_RETROGRADE (in an angle), else MODIFIED, with its explanation and implications, and the house signification adjustment (add the 7th from the occupied house, reduce the occupied one). The type also names DELAYED_FULL, NEECHA_BHANGA, SEVERELY_WEAKENED and DENIED, which F066 retired and are no longer emitted. A planet neither retrograde nor near a station gets no row; 'retrograde_planets' and 'station_planets' name the ones that do. Returns '{ chart_info, retrograde_analysis: { retrograde_planets, station_planets, analyses: [{ planet, is_retrograde, speed_deg_per_day, station_status, occupied_house, primary_results_house, secondary_results_house, sign, dignity, is_combust, neecha_bhanga: { applies, reason, trigger_planet, trigger_house }, dignity_provenance, verdict, verdict_explanation, implications, house_signification_adjustment: { add_houses, reduce_houses } }] }, houseConvention }'. Reads no aspect. Never an input to a KP verdict. The same block 'get_aspects_and_strength' returns as 'retrograde_analysis'.
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. |
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_retrograde_verdicts",
"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.