Specialized analysis
Career Indicators
get_profession_indicators
Career analysis from the 10th-house CSL (Cuspal Sub Lord). Returns '{ chart_info, profession_indicators, ruling_planet_applications: { chart_verification, prediction_confirmations[], rpMoment, judgement, rulingPlanetsAtBirth, atBirth, verdictFrom, scoreProvenance }, pagination, pageNote }'. The career verdict lives in 'profession_indicators' and 'chart_verification', both of which repeat on every page; **'prediction_confirmations' is paged** (with 'atBirth.prediction_confirmations', page for page) and is the RP audit trail across every event, not the answer. The confirmations read the ruling planets of the MOMENT OF JUDGEMENT (KP Reader 4: the planets ruling the moment the matter is judged), which is 'judgement_datetime', default now, at the birth place unless a judgement place is given; each row's 'csl_verdict' is 'analyze_natal_promise''s verdict and 'promise_state' names it (promised, undecided for MIXED_ACTIVE, denied), and only a promised verdict counts toward 'confirmation_strength'. 'atBirth' is every row read again with the BIRTH ruling planets, labelled for rectification only; 'chart_verification' is a birth-time check and keeps the birth set. For richer career signature (8 named categories: IT/government/business/military/medicine/law/arts/education) use 'get_career_signature'. For profession nature description (sector, employment mode, leadership/technical/creative scores) use 'get_profession_description'. For job-change vs promotion timing use 'get_job_change_vs_promotion'. The two RP applications are also tools of their own, named in 'methodSeams': 'get_rp_event_confirmations' (the confirmations, paged) and 'get_rp_chart_verification' (the birth-time check).
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. |
| judgement_datetime | string | No | The moment the matter is judged, local wall clock at the birth place unless judgement_latitude/longitude are given (e.g. 2026-09-27T12:00:00). Defaults to now, and the result's `judgement` says so (`datetimeDefaultedToNow`). KP reads the ruling planets of THIS moment (KP Reader 4), not the birth moment; the birth set is reported beside it as `atBirth`. |
| judgement_latitude | number | No | Latitude of the place of judgement. Defaults to the birth latitude. |
| judgement_longitude | number | No | Longitude of the place of judgement. Defaults to the birth longitude. |
| judgement_utc_offset_minutes | number | No | UTC offset of the place of judgement in minutes. Defaults to the birth offset when the place defaults to the birth place. |
| judgement_time_zone | string | No | IANA time zone of the place of judgement (e.g. "Asia/Colombo"), instead of judgement_utc_offset_minutes: the offset in force there at judgement_datetime is read from the tz database. If both are given they must agree. |
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_profession_indicators",
"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.