Event timing

Elect a Meeting or a Negotiation

find_meeting_time

Elect the moment for a business meeting, a board meeting, a client pitch or a negotiation. Defaults to houses 3, 6, 9, 10 and 11, quoted from Jyotish Astro Secrets p.912: "Agreement, interview, negotiation, etc. are all denoted by the 3rd house from the 7th, that is the 9th house ... If the negotiations to be successful or useful, 11th house is to be scrutinized ... If it is for business, houses 10 and 6 has to be judged in addition to 3 and 9." 'subject' picks between groups the books state separately, and each is quoted rather than composed: 'business' takes 3-6-9-10-11 from the page above, and 'third_party_approval' takes 3-5-9-11 from decoded Reader 5 p.232 with a second witness at Astrology for Beginners p.798. 'partnership' resolves to the same group as 'business', deliberately: THE CORPUS STATES NO SEPARATE PARTNERSHIP ELECTION. It appeared to until 2026-08-13, when the run-in heading above the 3-6-9-11 sentence on decoded Reader 5 p.233 was found to decode to "To Sign the Letter for Scholarship ?" rather than to anything about partners. That group now belongs to the event it was printed under, and a partnership meeting is elected as a business meeting. If a user asks for a partnership-specific rule, say there is not one. IT IS NOT A COMPOSED RULE, AND NO COMPOSED RULE EXISTS TO IMPLEMENT. A later school, Kanak Bosmia's KP Muhurat, was read in full for this: he gives three worked rows for a discussion, all reading the 3rd cusp, but he never states a general rule that builds a house group out of the 3rd cusp plus the subject's own houses, and two of his three rows leave the subject's own house out of the group entirely. Nothing of that shape is generated here. If a user asks where a meeting rule comes from, this is the honest answer. REPORT THE COUNTERPARTY FRAME. Each window carries 'nativeRisingFrame' with 'natalHouseRising', 'counterpartyHouse' and 'favoursTheNative'. The counterparty house is the native's house minus 6. Astrology for Beginners p.779 gives the mechanism, "the 5th house of the native is the 11 th house of the other person", and p.796 gives the reading that the native's 2, 6 and 11 rising are the moments the other party grants the request, because they are the other party's 8, 12 and 5. Say both numbers when you report a window. ASK FOR THE MEETING'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. Office hours, a board's calendar and a counterparty's diary all fix the window before any chart does, and KP elects inside it. It is the single biggest improvement to this answer. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, nativeRisingFrame, matchedConditions[], discriminator and rank. 'nativeRisingFrame' is null below minute granularity. There is no score and no top ten. A SECOND SCHOOL CAN CROSS-CHECK THIS, AND YOU SHOULD OFFER IT FOR ANY DATE THAT MATTERS. Pass 'bosmia_lens: true' only after the user agrees. Words that work: a second KP school reads the elected moment from the muhurta chart's own cusps rather than from your birth chart, and I can run it as a cross-check. It is not an upgrade and not a premium option, it is a different school reading the same moment. With it on, each window gains 'bosmiaLens' carrying 'verdict' and a one line 'verdictLine', plus 'checks[]' naming what passed and what did not. The two schools genuinely differ, so a disagreement is expected and is information, not a warning about the date, and where they conflict the KP books decide. It never removes or reorders a moment. On a meeting specifically, expect the second school to return 'verdict: NOT_IN_BOSMIA_TABLE', because it has no rule for a business meeting and none was invented. It still reads how long the thing being started is likely to last. Say that plainly rather than presenting it as a failure. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the agreement. Report windows in startLocal and endLocal, never in UTC.

Parameters

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