Skip to content
docs
UseBuildChangelog
Open Lumin
All tools

Advanced techniques

The Sixteen Tajik Yogas [Tajik]

get_tajik_yogas

[Tajik] Tajik's OWN judgement mechanism, which this engine did not have before 2026-09-14. The sixteen shodasha yogas under the Tajikanilakanthi's own definitions (Samjnatantra ch. 2, Kedaradatta Josi's edition, read verse by verse in Gansten and Wikander, Annals of Science 68, 2011), with the orb table from Daivajnalamkrti 8.9 (Gansten's critical Hayanaratna). Every instance carries 'reading' and its own source. Returns every one of the 21 planet pairs as a 'contact' (its aspect, separation, pair orb, and whether it is ithasala/applying, isarapha/separating or partile) plus each yoga instance with the planets, the reason, a sense word, and its own locus and edition. Read 'roles': the muthasila is the faster planet applying its light and the musaripha the slower one receiving it, and which is which decides whose condition the outcome turns on. NOT PARASHARI: an aspect here is one of the five Ptolemaic angles counted sign to sign AND gated by the pair orb (half the sum of the two planets' deeptamsas), so a sign aspect is inactive unless the degrees are close enough, and application is decided by DEGREE WITHIN SIGN rather than by longitude. ALL SIXTEEN COMPUTE since 2026-09-28 (F144): 'yogas' carries the TNK readings, including khallasara (2.61, the void-of-course Moon) and duhphalikuttha (2.64). The one-line research paraphrases this tool ran before (reading 'q031', class modern), Sahl's jam' where the TNK departs from him ('sahl') and Narasimha Rao's manual where it is a third definition ('narasimha-rao') ship in 'otherReadings', with 'presentUnderOtherReadings'; none of them decides anything in 'yogas'. Kuttha and durupha are, in the TNK, per-planet LISTS of strengthening and weakening conditions with no count that makes either present, so they ship in 'strengthConditions', each condition met or not, with no verdict; the paraphrase's two-planet kuttha and duruhpha stay in 'yogas' labelled 'q031', and only that reading is 'two-sided'. 'notComputed' names what is still not computed (the TNK's sixteen kambula grades, three of Narasimha Rao's variants) with the reason. Nakta is TRANSFER (naql: separating from one, applying to the other) and yamaya COLLECTION (jam'), F143. 'contacts[].poorna' marks an ithasala within an arcminute of exact (TNK 2.18, Sahl), with 'poornaHalfMinute' and the manuals' 'poornaWithinOneDegree' beside it (F142). NOTHING IS SCORED, because Tajik judges in words and the source gives no weighting. Pass 'target_year' to scan that year's solar-return chart (Tajik's native frame, same return instant as get_varshaphala_chart) or omit it for the natal chart. 'orb_table' selects the classical values or the circulating variant that gives Mars and Mercury 12; measured over 200 charts the two disagree about which yogas are present on 24.5% of them, so 'underOtherOrbTable' is reported every time. **'bala' carries Tajik's two strength systems, both of which compute in full since 2026-09-14.** Panchavargeeya bala scores each planet out of 80 across five components and reports the total, the classificatory value (the total over four, a 0 to 20 scale) and the band: Nirbali below 5, Madhya Bali 5 to 10, Poorna Bali 10 to 15, Parakrami above 15, with Raman's parallel words beside them. Four components score the planet's relation to the lord of a division it occupies, on one ladder every time (own the full maximum, a friend half, an enemy a quarter); the fifth, uccha bala, is continuous. The hadda table is the Tajik one as transmitted, and it is verified against the Egyptian terms it descends from: the two differ in exactly two signs and those are left uncorrected, because this records what the tradition states rather than what a scholar reconstructs it should have said. Harsha bala now runs all four situations for its stated 20 (15 on the natal frame, where there is no solar return to be day or night, so that component is absent rather than zeroed); its planetary genders are the TAJIK ones, where Mercury and Saturn are female, and its sect lists are the HELLENISTIC ones, where Saturn is diurnal and Venus nocturnal, the opposite of BPHS on both. **THREE THINGS SHIP AS VARIANTS RATHER THAN CHOICES** and every reading carries all three: the neutral rung is unstated in every component so both totals ship ('total' and 'totalNeutralAsFriend'), the uccha reference point is a disagreement the source names, and the harsha gender test is applied to the sign by one source and to the house by another, so 'genderTestVariant' carries both answers. Read 'bala.gaps' for what is still open in one place. **'dashas' appears on the annual frame only** and carries Tajik's two annual dashas, both computed. **Mudda** is computed: the Vimshottari compressed into a year, each planet's Vimshottari years times three giving its days, in Vimshottari order from the lord given by (natal Moon nakshatra + completed years - 2) / 9 with the remainder COUNTED FROM THE SUN (1 Sun ... 8 Ketu, 0 Venus), which is the natal Moon's nakshatra progressed one a year; Adawal's and Narasimha Rao's worked examples fix it (until 2026-09-28 the engine opened every year one lord early, F141, and 'superseded' says what it returned). The first period is a BALANCE, the part of the natal Moon's nakshatra still to traverse, and the traversed remainder closes the year ('segment' on each period). Three year lengths ship and none is preferred: 'periods' the stated 360 civil days (ending ~5 days short of the next return), 'periodsScaledToYear' Adawal's proportional spread over the real year, 'periodsBySolarDegrees' a mudda day as the Sun's one degree (Narasimha Rao), ending at the next return. 'annualMoonVariant' opens the year on the ANNUAL Moon's own nakshatra lord with its own balance, a modern alternative; 'startingLordUttaraKalamrita' keeps its old value, a hybrid no source states, labelled. **Patyayini is computed, and it is the one annual dasha NATIVE to Tajik** rather than a compression of a Parashari nakshatra cycle, which is why it takes the ascendant as a full dasha lord and excludes Rahu and Ketu, the opposite of mudda. It divides the year among the seven planets and the lagna in ASCENDING order of krishamsa, the longitude with the signs deleted; each lord's patyamsa is its krishamsa less the previous lord's, and each period is the year times its patyamsa over the highest krishamsa. **It is a LONGITUDE rule and not a strength rule**: nothing in it reads panchavargeeya bala, and the 'divide by four' that connects the two in some summaries belongs to the year-lord classification, a different rule in a different chapter (this engine had that conflation and it cost a working technique a day; see 'invariantHolds'). The rule carries its own arithmetic check and the response reports it: the patyamsas are successive differences of a sorted list, so they MUST total the highest krishamsa. Three year lengths are attested and all three ship per period, the flat 365 being primary because it is what the source's worked example is computed on. Mudda is a CROSS-CHECK by its own doctrine, read together with the natal Vimshottari dasha, so pair it with get_dasha_periods rather than reading it alone. Four of the yogas read a planet as 'afflicted' and panchavargeeya bala is what that means; it now computes, so 'bala' and the yoga scan can be read together on one call rather than the scan naming a gap it cannot fill. Four blocks are also tools of their own, named in 'methodSeams': 'bala.panchavargeeya' is 'get_panchavargeeya_bala' and 'bala.harsha' is 'get_harsha_bala' (each paged by planet), and on the annual frame the year lord in 'annual' is 'get_varshesha' and 'dashas' is 'get_tajik_dashas'. Call those when a reading needs one claim; this tool still returns every block.

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_yearnumberNoScan that year's solar-return (annual) chart, Tajik's native frame. Omit for the natal chart.
orb_tableenum: classical | popularNoclassical = Daivajnalamkrti 8.9 (Sun 15, Moon 12, Mars 8, Mercury 7, Venus 7, Jupiter 9, Saturn 9), the critical edition and the default. popular = the circulating variant with Mars and Mercury at 12.

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