Advanced techniques
Paradigm Panel (one matter, every system, as parallel arguments)
get_paradigm_panel
Reads ONE matter (marriage, career or health) through every system this engine implements and returns them as parallel arguments, never as a verdict. Seven systems: KP, KCIL, Four Step and Bosmia (the KP lineage, which DO define a promise procedure), plus Parashari, Jaimini and Tajik (which do not). **It is a reader, not a judge.** A system that defines no promise gate returns 'NO_VERDICT_PROCEDURE' with its findings, and a system with no route to the matter returns 'SILENT' with the reason, because manufacturing a Parashari PROMISED to fill a column would be fabricating a tradition's opinion. That is the panel's main finding: KP's distinguishing feature is that it HAS a verdict procedure, while Parashari and Jaimini give significators rather than a gate. Tajik reads a YEAR, so it is silent on natal promise until 'target_year' is named, and what it says then is about that year and is not comparable with a natal verdict. Every claim carries a source class ('corpus', 'classical', 'disputed', 'later', 'derived', 'unsourced', 'unattributed', the last meaning standard practice this repo has not pinned to an edition and a locus), and 'unattributedClaimCount' says how many claims in the panel rest on nothing verified. **There is no score, no average, no consensus figure and no vote**: the systems disagree about what a promise is, so a tally would present incommensurable claims as commensurable ones. Instead 'disagreement.type' names HOW they relate (CONCORDANT, CONCORDANT_ON_DIFFERENT_GROUNDS, SPLIT_VERDICT, TIMING_DIVERGENCE, SINGLE_VOICE, NO_VERDICT_TO_COMPARE) and 'sharedGrounds' names the houses and planets two systems literally have in common. Pass 'frames' to cross the panel with the ayanamsa axis and learn which of these conclusions survive a change of zero point. Present the arguments to the user; do not resolve them.
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. |
| matter | unknown | Yes | The matter to read. Required. |
| systems | unknown | No | Systems to include. Default: all seven. |
| event | unknown | No | Override the matter's default KP event key (marriage -> Marriage, career -> Career / Job Start, health -> Chronic Illness). |
| target_year | unknown | No | Naming a year is the only thing that makes Tajik speak. |
| frames | unknown | No | no description |
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_paradigm_panel",
"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.