Skip to content
docs
UseBuildChangelog
Open Lumin
All tools

Advanced techniques

Tajik Strength Variant Spread (what the unresolved readings actually change) [Tajik]

get_tajik_variant_spread

[Tajik] The sibling of get_frame_spread, for Tajik's strength systems instead of the ayanamsa. get_tajik_yogas computes panchavargeeya and harsha bala on one reading and reports the variants beside them; this answers the question that reporting them does not, which is WHICH CONCLUSIONS MOVE when a reading the sources leave open is taken the other way. Measured over 200 charts THROUGH THIS TOOL ('scripts/bp017-tajik-variant-spread.ts'): the unstated neutral rung arises on 62.5% of planet readings, moves a planet's BAND on 17.7% of them and on 74.0% of charts, and moves the chart's greatest panchavargeeya bala (A45's year-lord tie-break input) on 15.0% of charts; the harsha gender test disagrees with itself on 49.3% of planet readings and somewhere on 98.5% of charts. READ 'movesAt' PER PLANET, NOT 'summary.variantIndependent': one planet in five (19.9%) moves on NOTHING and its strength can be stated without a hedge, but a chart where NOTHING AT ALL moves is rare (0.5%), because the gender test disagrees on some planet almost every time. The per-planet answer is the usable one and the whole-chart flag is the rare strong case. Returns per planet both panchavargeeya totals, both classificatory values, both bands, both harsha gender readings and both harsha point totals, plus 'movesAt' naming which of the four axes actually moved. READ THE EMPTY 'movesAt' FIRST: a planet listed in 'summary.holding' has a strength reading that does not rest on anything the sources leave open, and that can be said outright instead of hedged. 'greatestPanchavargeeya' names the greatest planet under each reading because A45's second test asks for it; IT IS NOT THE YEAR LORD, and reading it as one is the mistake Q034's own worked example catches, where the chart's strongest planet loses the varshesha because it does not aspect the annual ascendant. Pass 'target_year' for the annual frame and 'yearLord' carries A45's answer under each reading, with 'annual.aspecting' and 'annual.strengths' so a caller can see whether the rung was even consulted: the year lord holds far more often than the strongest planet does, because the aspect gate decides first and the tie-break only runs inside it. FOUR VARIANTS TRAVEL AND ONLY TWO ARE COMPUTED. The neutral rung (A43 states no value for a neutral relation in any of its five components) and the harsha gender test (A44 reads the sign, Q034 reports the house) are computed both ways. The uccha reference point and the friendship scheme are NAMED AND LEFT UNMEASURED, because their second readings have no stated arithmetic and inventing the transformation in order to measure it is exactly the failure this surface exists to avoid. NOTHING IS SCORED, RANKED, AVERAGED OR VOTED ON and there is no best reading: a reading either changes a conclusion or it does not.

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.
target_yearnumberNoRun the spread on that year's solar-return (annual) chart and include the year lord under each reading. Omit for the natal chart, which reports every strength variant but no year lord, because there is no year to have one.

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_tajik_variant_spread",
    "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.