Advanced techniques
Classical Shadbala (BPHS ch. 27) in virupas [Parashari]
get_classical_shadbala
Parashari, not KP. The Shadbala of Brihat Parashara Hora Shastra ch. 27 (Santhanam) in VIRUPAS, 60 to a rupa, for the seven planets; Rahu and Ketu have none (BPHS computes it for the seven only). Returns '{ method: 'bphs-shadbala', planets: [{ planet, sthana, dig: { virupas, fullStrengthHouse, measuredFromCusp, arcDeg }, kala, chesta, naisargika, drik, totalVirupas, totalRupas, requiredVirupas, requirementRatio, verdict: STRONG | WEAK, minorityRequirement, componentMinimums, ishtaPhala, kashtaPhala, rank }], strongest, weakest, variants: [{ key, reading, source, totals, verdictsChanged, strongestChanged, strongestUnderVariant }], componentProvenance: [{ component, source }], methodNote, warnings, houseConvention }'. Each planet carries every sub-part of the six balas (Sthana's Uccha, Saptavargaja, Ojha-Yugma, Kendra and Drekkana; Kala's Nathonnatha, Paksha, Tribhaga, the Abda, Masa, Vara and Hora lords, Ayana and the 27.20 graha-yuddha correction; Chesta from the motion states; Drik over the sputa drishti scale), their sum against the planet's own 27.32-33 requirement ('verdict' is absolute: Mercury at 419 against 420 is weak), the 27.34-36 component gates ('componentMinimums', with 'attainable' and 'failedAttainable' because one transmitted gate cannot be passed, F083), and Ishta and Kashta phala. 'strongest' and 'weakest' are the selector 27.37-38 asks for. 'componentProvenance' names the one component that is not the classical quantity (Chesta, which needs a mean planet this engine does not compute); 'variants' gives each editorial dispute as its own totals and what it moves, none averaged. 'houseConvention' says Dig bala is measured from the Placidus cusps (27.7). **'planets' is paged, one planet per page in rank order**, never cut inside a row; everything else repeats on every page, so 'strongest', 'weakest' and the 'variants' totals read from page 1. The Lumin 0-100 index is 'get_shadbala_index', a different quantity: never compare the two figures. Gates no KP verdict. The same block 'get_shadbala' returns as 'classical', with its 'houseConvention'.
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_classical_shadbala",
"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.