Event timing
Elect a Wedding Muhurta
find_wedding_muhurta
Elect the moment for a marriage ceremony. Elects on houses 2, 7 and 11: the 7th is the marriage itself, the 2nd the family it forms, the 11th the fulfilment of the desire. SAY WHERE THAT GROUP COMES FROM IF ASKED, because it is not a wedding muhurta rule. The corpus states no electional house group for a wedding anywhere. 2, 7 and 11 is its marriage JUDGEMENT group, printed as prose at Astrology for Beginners p.312 ("for marriage, houses 2, 7, 11 are beneficial"), as a list row at p.313, and applied to natal marriage timing at decoded Reader 4 p.127 ("Houses 2, 7 and 11 are judged."). The election reuses it. The one worked wedding election in the corpus, Jyotish Astro Secrets pp.139-142, uses no house group at all: it elects from the bride's dasa chain and the Lagna touching her natal Moon. Read 'provenanceSummary.quoteNote' for this in the response. ASK FOR THE COUPLE'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. A wedding is booked inside a hall's hours, a registrar's appointment or a family's plan, and KP elects inside a window the world has already fixed rather than ranking every minute of a week. It is the single biggest improvement to this answer. Pass 'person2' to run the two chart form. TWO CHART ELECTION IS A LUMIN EXTENSION, NOT KP CANON, and you must say so when you use it: the corpus holds exactly one worked two chart election in 6,465 pages and it is a single chart election with a post hoc check of the second chart, with no rule for what to do when the two disagree. With 'person2' the response gains 'secondaryCheck' per window, reading CONFIRMS, PARTIAL or CONTRADICTS, plus 'extensionNote'. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }', or the joint shape '{ mode, primary, secondary, windows[], scanSummary, provenanceSummary, extensionNote, disclaimer, summary }' when 'person2' is present. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score. KP has no numeric strength for a moment, so nothing is ranked 0 to 100 and there is no top ten. The single chart form returns ONE moment, or up to three when the selection tests cannot separate them. The two chart form deliberately returns the wider pool instead, up to ten, because the second chart still has to filter what the first elected: order matters there and 'rank' 1 is the elected moment. Quote 'discriminator' for why a moment won, and read 'resolvingLayer' before quoting a width, since an Ascendant-sub election is minutes wide and a Moon-sub election is hours wide. 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. Bosmia's own row for a wedding reads the 7th cusp of the muhurta chart against houses 2, 7 and 11, so on a wedding the two schools start from the same houses and differ only on which chart they read. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the marriage or its quality. Report windows in startLocal and endLocal, never in UTC.
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. |
| bosmia_lens | boolean | No | no description |
| scan_start | string | No | First moment to consider, ISO 8601. A bare datetime is read as local time at the place of the action. Defaults to now. |
| scan_days | number | No | Days to scan. Clamped by granularity: 365 for day, 90 for hour, 30 for minute. Default 7. |
| granularity | enum: day | hour | minute | No | Election precision. 'minute' runs the Ascendant layer and gives the narrowest window, 'hour' stops at the Moon sub, 'day' groups by local civil day. Defaults to this event's own default. |
| preferred_time_of_day | object | No | What this window is, for example "office hours" or "before the registrar closes". Echoed back in the response. |
| event_latitude | number | No | Latitude of where the action happens. Defaults to the birth latitude. KP computes the Ascendant for the place of the action, not the place of birth. |
| event_longitude | number | No | Longitude of where the action happens. Defaults to the birth longitude. |
| event_utc_offset_minutes | number | No | UTC offset at the place of the action, in minutes. Defaults to the birth offset. Drives every local time in the response. |
| max_windows | number | No | Override the default output shape and take a pool of up to 25 instead of the one elected moment. Only use this when the user explicitly asks to see the whole field. |
| person2 | object | No | The other partner's birth chart. Optional. When given, the moment is elected from the FIRST chart and checked against this one. |
| primary_role | string | No | Label for the first chart, for example 'bride'. |
| secondary_role | string | No | Label for the second chart, for example 'groom'. |
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_wedding_muhurta",
"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.