Skip to content
docs
UseBuildChangelog
Open Lumin
All tools

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

NameTypeRequiredDescription
birth_datetimestringYesBirth date and time in ISO 8601 format (e.g., "1990-05-15T14:30:00").
latitudenumberYesBirth location latitude. Range: -90 to 90.
longitudenumberYesBirth location longitude. Range: -180 to 180.
utc_offset_minutesnumberYesUTC offset in minutes (e.g., 330 for IST, -300 for EST).
ayanamsaenum: kp | kp_new | lahiri | raman | true_chitra | khullarNoAyanamsa system. Defaults to kp.
matterunknownYesThe matter to read. Required.
systemsunknownNoSystems to include. Default: all seven.
eventunknownNoOverride the matter's default KP event key (marriage -> Marriage, career -> Career / Job Start, health -> Chronic Illness).
target_yearunknownNoNaming a year is the only thing that makes Tajik speak.
framesunknownNono description

Example call

Send the request as a standard MCP tools/call:

http
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.