Advanced techniques

Horary and Natal Fruitful Cross-check

get_horary_natal_crosscheck

Do the birth chart and the horary chart select the same fruitful significators for the matter? Casts the horary chart from the number (Ascendant fixed at the commencement of its sub, KP Reader 6) at the moment of the question ('judgement_datetime', default now, at the birth place unless 'judgement_latitude'/'judgement_longitude' are given, with 'judgement_utc_offset_minutes' or 'judgement_time_zone'), takes each chart's fruitful significators for the event (significators of its houses that are also that chart's Ruling Planets; the natal set uses the BIRTH Ruling Planets, which is the rectification use), and compares them. Returns '{ technique, queryEvent, requiredHouses, natalFruitfulCount, horaryFruitfulCount, intersectionPlanets, convergenceRatio, convergenceLevel, details: [{ planet, inNatal, inHorary, natalLevel, horaryLevel }], summary, scoreProvenance, horaryAscendant, horaryMoment, deprecatedInput }'; 'deprecatedInput' names any old field name the call used and the field to send instead. A claim about the birth chart: divergence suggests checking the birth time. The ratio divides by the smaller set and the HIGH / MODERATE / LOW bands are unsourced ('scoreProvenance'). Read 'intersectionPlanets' and 'details'. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only; the same block 'get_horary_ruling_planets_variants' returns given the same judgement_datetime, named in 'methodSeams'.

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.
target_number	number	Yes	KP horary question number
judgement_datetime	string	No	The moment the question is judged, as the local wall clock at the place of judgement, ISO 8601 with no zone suffix (e.g. 2026-10-20T10:30:00). Defaults to now, and the result's horaryMoment says so.
judgement_latitude	number	No	Latitude of the place where the question is judged, north positive.
judgement_longitude	number	No	Longitude of the place where the question is judged, east positive.
judgement_utc_offset_minutes	number	No	UTC offset in force at the place of judgement at that moment, in minutes east of UTC (e.g. 330 for India, -240 for New York in summer). Prefer judgement_time_zone, which works it out; if both are given they must agree.
judgement_time_zone	string	No	IANA time zone of the place of judgement (e.g. "Asia/Colombo", "America/New_York"). The offset in force there at judgement_datetime is read from the tz database, daylight saving and past changes included.
query_datetime	string	No	Deprecated, use judgement_datetime.
query_latitude	number	No	Deprecated, use judgement_latitude.
query_longitude	number	No	Deprecated, use judgement_longitude.
query_utc_offset_minutes	number	No	Deprecated, use judgement_utc_offset_minutes or judgement_time_zone.
query_event	string	Yes	The event or question being queried, as an event name (e.g., 'Marriage', 'Career / Job Start').

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_horary_natal_crosscheck",
    "arguments": {
      "birth_datetime": "1992-08-14T04:32:00",
      "latitude": 6.927,
      "longitude": 79.861,
      "utc_offset_minutes": 330,
      "ayanamsa": "kp",
      "target_number": 137,
      "query_event": "..."
    }
  }
}

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.