Advanced techniques

Horary Number Intuition

get_horary_number_intuition

Does the number the querent chose point at the question asked? Casts the horary chart 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') with the Ascendant FIXED at the commencement of the sub the number names (KP Reader 6), takes that Ascendant's sub lord, and reports which of the event's required houses it signifies in the horary chart. Returns '{ technique, questionNumber, queryEvent, requiredHouses, horaryAscendantLon, subLord, subLordSignifiedHouses, overlapHouses, overlapRatio, verdict, explanation, summary, scoreProvenance, horaryAscendant, horaryMoment, deprecatedInput, numberMethods }'; 'deprecatedInput' names any old field name the call used and the field to send instead. 'verdict' is SELF_CONFIRMATORY at an overlap of 0.67 or more, WEAKLY_CHOSEN above 0, CONTRADICTORY at 0, and **the 0.67 line is unsourced**: Q041 searched the KP Readers, Astrology & Athrishta 1963-1971 and modern KP sources and found nothing for it ('scoreProvenance'). This is not a validity test. KSK holds the number valid in itself, gated only by its range, and no source makes the number agree with the Ruling Planets. 'numberMethods' carries the methods that do exist, side by side, none picked: [KP] KSK's self-validating number with its range gates; [KP-extended] the Gulbarga short method (Murthy and Purushottama, 1971, a yes / probable / no verdict rule, with Reader 6's counter-cases), the KP E-zine 2009 Moon-and-Ascendant test, and Prabhakar c.2006's number ruling planets (disputed). Report the houses, not the label, and each method under its own name. 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. 'numberMethods' and 'rulingPlanetsVariants' are also tools of their own, named in 'methodSeams': 'get_horary_number_methods' and 'get_horary_ruling_planets_variants' return the same blocks given the same judgement_datetime.

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