Skip to content
docs
UseBuildChangelog
Open Lumin
All tools

Advanced techniques

Modern Occupation Leanings from the 10th Cusp Triad (KP, weakest-confidence tool)

get_occupation_matches

Which kinds of modern work a chart leans toward, scored off the 10th cusp TRIAD rather than a ninefold planet lookup. The method is KSK's own three steps at KP Reader 3 printed 327-328: study what each sign indicates, understand what each planet denotes, then combine the rasi and the planet at the meridian. His worked example is explicit, that the meridian's sign lord, star lord and sub lord together indicate the profession, so this tool scores those three and not the sub lord's own star lord (get_profession_description walks that deeper chain for a different question). Scoring layers: triad planet overlap, supporting planet overlap, the meridian sign, domain-house activation through the significator matrix, and the 2/6/10/11 career base. NODE HANDLING: Rahu and Ketu are never scored as themselves. In KP a node carries no karakatva of its own and acts as an agent for its star lord, its conjunctions and its sign lord (KP Reader 6 p.274; KP Reader 3 p.356, 'For Rahu and Ketu, one is to note in which constellation it is and then according to the lord of the constellation ... one is to offer the prediction'), so node slots are resolved and the resolved planet scores, with every substitution listed in 'nodeResolution[]'. PROVENANCE MODEL, read this before quoting any result: each occupation carries 'provenance', one of BOOK_SOURCED (a KP text names it directly in a profession context), ANCESTOR_DERIVED (inherited from a named older occupation the books do carry, with the ancestor recorded so the leap is one auditable step) or PRINCIPLE_DERIVED (no KP text predates the occupation, so the signature was assembled from planet, sign and house significations, which is a reasoned construction and not a citation). 'provenanceSummary' reports the mix at the top level. CONFIDENCE CAVEAT: this is the weakest tool in the career suite and is built to say so. KP is strong on whether a career is promised, on whether it runs as service or one's own concern, and on when the ground shifts; it is weakest at naming an occupation, and KP's own literature says so, since Tin Win, reviewing the standard KP profession text in KP Ezine October 2010, wrote that 'The precise rules which are valid for a bulk of empirical charts have not yet been found.' 'topFamilies' is the headline answer and 'matches' is capped at 12 as illustration, never a shortlist. 'noSettledOccupationFlag' trips when the career balance is HEAVILY_OBSTRUCTED or the Jyotish Part 1 p.359 denial gate fires (a 10th CSL signifying none of 6, 7 or 10), and the matches are then inclinations rather than a career. Returns '{ tenthCuspTriad, planetLayer[], signLayer[], houseLayer, nodeResolution[], topFamilies[], matches[], noSettledOccupationFlag, provenanceSummary, summary, disclaimer }'. Phrase every result as 'leans toward' or 'is consistent with'. Never say what someone is, and never use this to screen, rank or decide about anyone.

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.
limitnumberNoMaximum individual occupations to return (default 12, hard cap 12)
familiesarray<unknown>NoRestrict scoring to these occupation families, e.g. SOFTWARE_AND_DATA, HEALTH_AND_MEDICINE

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