Kundlit Vedic Astrology

Free Vedic astrology: panchang, kundali, transits, matching, doshas, eclipses, numerology

¿Debería usar esto?

Calidad y seguridad

A
Calidad de la descripción
100%
Integridad del esquema
98%
Calidad de los nombres
100%
Riesgo de envenenamiento
100%
Coincidencia de permisos
100%
Cumplimiento del protocolo
100%

Basado en el análisis automatizado de las definiciones de herramientas y el cumplimiento del protocolo.

Costo de contexto

~12,300Tokens (definiciones de herramientas)
~4.8 KBTamaño de respuesta típico
Impacto significativo en la atención (9.61% del contexto de 128k)

Este es el número aproximado de tokens que se consumen cada vez que las herramientas del servidor se cargan en el contexto de un modelo. Los recuentos más altos reducen la atención disponible para otras tareas.

Instalar

Instalación con un clic

Agrega esto a tu archivo `claude_desktop_config.json`:

{
  "mcpServers": {
    "astro": {
      "command": "npx",
      "args": [
        "@kundlit/mcp"
      ]
    }
  }
}

Paquetes ejecutables

npm@kundlit/mcp1.0.1stdio

Puntos de conexión remotos

https://kundlit.com/api/mcpstreamable-http

Qué puede hacer

Inventario de herramientas

Herramientas (17)

🟢 Solo lectura🟡 Escritura🔴 Eliminación⚪ Desconocido
🟢get_panchang(date, place, latitude, longitude, timezone)

Returns the Hindu panchang (daily Vedic almanac) for one date at one place: the five angas (tithi with paksha, nakshatra, yoga, karana, vara with its weekday lord) each with its end time, the lunar month in AMANTA reckoning with its adhika-masa flag (omitted entirely, never substituted, if the engine cannot supply the amanta month; plus the purnimanta month where the engine supplies it), sunrise/sunset/moonrise/moonset, abhijit muhurta, the auspicious choghadiya windows, and the inauspicious periods (rahu kaal, yamaganda, gulika kala). Use this for 'what is today's panchang / tithi / nakshatra' questions. If the user wants the FULL timing surface (all 16 choghadiya, the 24 horas, varjyam, bhadra, panchak, brahma muhurta) to choose a moment for an activity, call get_muhurta_timings instead. Nakshatra here is the DAY's nakshatra, not a person's birth star -- for that use get_birth_details. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Any city worldwide; window times derive from that location's actual sunrise and sunset, so they differ city to city on the same date.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "date": {
      "description": "Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit to get today's date at the given place (not the server's date).",
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_janam_kundali(birth_date, birth_time, place, latitude, longitude, ...)

Returns a full Vedic birth-chart (janam kundali) summary for one person from their birth date, time and place: the lagna (ascendant) with sign, nakshatra, pada and lord; all nine grahas with sidereal sign, house, nakshatra, pada, dignity and retrograde/combust flags; the currently running Vimshottari mahadasha and antardasha with end dates, omitted only for a chart cast at the present moment, where no dasha has yet elapsed; and the most notable classical yogas detected, with a count of how many were found in all. Use this when the user wants their whole chart read. Prefer the cheaper, narrower sibling when the question is narrow: get_birth_details for only nakshatra / moon sign / lagna, get_dasha_periods for the full dasha timetable, get_upapada_arudha for the Jaimini layer, get_transits for where the planets are RIGHT NOW rather than at birth. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. Accuracy depends on birth-time precision.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_kundli_match(person_a, person_b)

Returns classical Ashtakoot marriage compatibility (kundli milan / gun milan) between two people from both birth charts: each of the eight koots (varna, vashya, tara, yoni, graha maitri, gana, bhakoot, nadi) with points earned out of its maximum, the total out of 36, any koot-level dosha, the classical cancellation that applies to it if one does, and an overall verdict. Use this whenever real marriage matching is asked for. get_love_compatibility is name-numerology entertainment and is NOT a substitute. Nadi/bhakoot dosha reported here is chart-pair compatibility, not the individual Mars dosha -- for that call check_manglik on each person. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Both people need an exact birth time and place.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "person_a": {
      "type": "object",
      "properties": {
        "gender": {
          "type": "string",
          "enum": [
            "male",
            "female"
          ],
          "description": "Either \"male\" or \"female\". Required: several koots (varna, vashya, gana, bhakoot) are scored asymmetrically between the two charts under the classical rules."
        },
        "birth_date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
        },
        "birth_time": {
          "type": "string",
          "pattern": "^\\d{2}:\\d{2}$",
          "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
        },
        "place": {
          "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
          "type": "string",
          "minLength": 1,
          "maxLength": 160
        },
        "latitude": {
          "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
          "type": "number",
          "minimum": -90,
          "maximum": 90
        },
        "longitude": {
          "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
          "type": "number",
          "minimum": -180,
          "maximum": 180
        },
        "timezone": {
          "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
          "type": "string",
          "minLength": 1,
          "maxLength": 64
        }
      },
      "required": [
        "gender",
        "birth_date",
        "birth_time"
      ],
      "description": "First person: gender plus birth date, birth time and place (or coordinates + timezone)."
    },
    "person_b": {
      "type": "object",
      "properties": {
        "gender": {
          "type": "string",
          "enum": [
            "male",
            "female"
          ],
          "description": "Either \"male\" or \"female\". Required: several koots (varna, vashya, gana, bhakoot) are scored asymmetrically between the two charts under the classical rules."
        },
        "birth_date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
        },
        "birth_time": {
          "type": "string",
          "pattern": "^\\d{2}:\\d{2}$",
          "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
        },
        "place": {
          "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
          "type": "string",
          "minLength": 1,
          "maxLength": 160
        },
        "latitude": {
          "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
          "type": "number",
          "minimum": -90,
          "maximum": 90
        },
        "longitude": {
          "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
          "type": "number",
          "minimum": -180,
          "maximum": 180
        },
        "timezone": {
          "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
          "type": "string",
          "minLength": 1,
          "maxLength": 64
        }
      },
      "required": [
        "gender",
        "birth_date",
        "birth_time"
      ],
      "description": "Second person: same fields as person_a. Their birth place may differ from person_a's."
    }
  },
  "required": [
    "person_a",
    "person_b"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢check_manglik(birth_date, birth_time, place, latitude, longitude, ...)

Returns a yes/no Manglik (Mangal / Mars dosha) verdict for ONE person's birth chart, with severity (none, mild, medium or high), which of the three classical reference points trigger it (Mars counted from the ascendant, from the Moon, from Venus), the classical cancellations that apply, and the traditional remedies for it. Use this for 'am I manglik / do I have mangal dosh' questions, and run it per person before a marriage discussion. It scores ONE chart -- for the two-chart compatibility score use get_kundli_match; for the Rahu-Ketu hemming dosha use check_kaal_sarp. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Remedies are the classical prescriptions, reported as data and not as advice.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_sade_sati(birth_date, birth_time, place, latitude, longitude, ...)

Returns a person's Sade Sati status -- Saturn's roughly 7.5-year passage over the sign before, the same as, and the sign after their natal Moon: whether it is currently active, the phase (rising / peak / setting) with its start and end dates, the phases still to come, the natal Moon rashi, Saturn's sign now, and dhaiya (small panoti) status. Use this for 'when does my sade sati start/end' and 'am I in shani sade sati' questions. This is Saturn-only; for where ALL nine grahas are transiting now (and their houses from the natal Moon) call get_transits. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Dates are computed, not predicted -- no interpretation of what the period will bring is returned.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    },
    "as_of_date": {
      "description": "Evaluate Saturn's position as of this date, YYYY-MM-DD, years 1200-2400. Omit for today. Use it to ask 'was I in sade sati in 2019' or 'will I be in 2031'.",
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢check_kaal_sarp(birth_date, birth_time, place, latitude, longitude, ...)

Returns a yes/no Kaal Sarp dosha verdict for ONE birth chart -- the condition where the seven classical grahas all fall on one side of the Rahu-Ketu axis -- plus which of the twelve named types it is (Anant, Kulik, Vasuki, Shankhpal and the rest), whether the hemming is full or partial, the houses involved, and a plain explanation of the finding. Use this for 'do I have kaal sarp dosh' questions. It is a different dosha from the Mars one (check_manglik) and from marriage-pair doshas (get_kundli_match); ask for each separately. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Needs an exact birth time -- partial hemming can flip with a few minutes' error.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_pancha_pakshi(birth_date, birth_time, place, latitude, longitude, ...)

Returns a PERSONAL timing schedule under Tamil Pancha Pakshi Shastra: it resolves the person's birth bird (Vulture, Owl, Crow, Cock or Peacock) from their birth details, then returns that day's ten yaamas -- five by day, five by night -- each with the acting bird and activity and a list of sub-periods carrying a 1-10 strength rating plus that bird's relation (friend / same / enemy) to the person's own bird. Use this when the user wants timings tuned to THEM. get_muhurta_timings and get_panchang give the same day's windows for everyone at that place with no birth details; this system is independent of them and the two can disagree. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa for the birth-bird nakshatra); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Yaama boundaries follow the location's actual sunrise and sunset, so the schedule is place-specific.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    },
    "date": {
      "description": "Day to schedule, YYYY-MM-DD, years 1200-2400. Omit for today at the given place. The birth fields identify the person; this field picks the day being planned.",
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_muhurta_timings(date, place, latitude, longitude, timezone, ...)

Returns every auspicious and inauspicious time window for one date at one place, in a single call: all 16 choghadiya with quality, the 24 planetary horas, rahu kaal / yamaganda / gulika kala, abhijit + brahma + vijaya + godhuli + nishita muhurta and the two sandhyas, amrita kalam, varjyam, dur muhurtam, bhadra windows, panchak and gand mool status, and disha shool (the travel direction to avoid that weekday). Use this to CHOOSE a moment -- 'best time to sign / travel / start work today'. Use get_panchang instead when the user only wants the day's tithi and nakshatra; use get_pancha_pakshi when the timing must be personalised from full birth details. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Windows are divisions of that location's actual sunrise-to-sunset day. If a window cannot be computed for the date the result names it under data_note as unknown rather than dropping it -- do not read absence as 'none today'.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "date": {
      "description": "Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit for today's date at the given place.",
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    },
    "janma_nakshatra": {
      "description": "Birth star in IAST, e.g. \"Rohini\" or \"Ashvini\" (spelling is matched loosely). Optional: supply it to add that person's tarabala verdict for the day. Omit and the tarabala block is left out entirely. Get the value from get_birth_details if unknown.",
      "type": "string",
      "minLength": 1,
      "maxLength": 40
    },
    "janma_rashi": {
      "description": "Birth moon sign, Sanskrit or Western -- \"Vrishabha\" and \"Taurus\" both work. Optional: supply it to add that person's chandrabala verdict for the day. Omit and the chandrabala block is left out entirely.",
      "type": "string",
      "minLength": 1,
      "maxLength": 40
    }
  },
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_year_events(year, category, month, place)

Returns dated Hindu calendar events for a whole year at one city. category='festival' lists every festival and vrat that year (Holi, Diwali, Navratri, Shivratri and the rest); the other categories list every ekadashi, purnima, amavasya or sankranti date. Each row is the exact local date and the event name, plus a one-line significance on shorter lists. Use this for 'when is X this year' and 'list all ekadashi dates' questions. For the detail of a single day (tithi, sunrise, rahu kaal) call get_panchang with that date; for eclipses call get_eclipses. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and results are computed for the nearest of 50 supported cities (a location_note names it when the snap is far); long lists are capped at 80 rows, so pass month to page through them.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "year": {
      "type": "integer",
      "minimum": -9007199254740991,
      "maximum": 9007199254740991,
      "description": "Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected."
    },
    "category": {
      "type": "string",
      "enum": [
        "festival",
        "ekadashi",
        "purnima",
        "amavasya",
        "sankranti"
      ],
      "description": "\"festival\" returns every event of the year; \"ekadashi\", \"purnima\", \"amavasya\" and \"sankranti\" each narrow the list to that lunar/solar family only."
    },
    "month": {
      "description": "Restrict the result to a single Gregorian month, 1 = January to 12 = December. Omit for the whole year. Use it when a year-wide list came back truncated.",
      "type": "integer",
      "minimum": 1,
      "maximum": 12
    },
    "place": {
      "description": "City as free text, e.g. \"Jaipur\" or \"Chennai, India\". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities, since tithi-based dates can differ by a day between distant longitudes.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    }
  },
  "required": [
    "year",
    "category"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_eclipses(year, place)

Returns every solar and lunar eclipse of a calendar year with local visibility for one city: eclipse type (total, partial, annular or penumbral), date, the sparsha (first contact), madhya (maximum) and moksha (release) times, the magnitude, and a locally_visible flag. That flag is the one that matters for practice -- sutak observance applies only where the eclipse is actually visible. Use this for 'which eclipses fall in this year' and 'is it visible here' questions, and for sutak timing. For festivals and vrat dates use get_year_events; for the rest of a day's almanac use get_panchang. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and visibility is evaluated for the nearest of 50 supported cities.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "year": {
      "type": "integer",
      "minimum": -9007199254740991,
      "maximum": 9007199254740991,
      "description": "Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected."
    },
    "place": {
      "description": "City as free text, e.g. \"Jaipur\" or \"Chennai, India\". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities; visibility and contact times are reported for that city.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    }
  },
  "required": [
    "year"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_numerology(birth_date, name)

Returns a Vedic numerology reading from a date of birth alone: the mulank (root / psychic number, from the day of the month) and the bhagyank (destiny / life-path number, from the whole date), each with its ruling planet and traditional meaning, plus the classical lucky attributions -- numbers, colours, weekday, direction, gemstone. Optionally adds the Chaldean naam-ank when a name is supplied. Use this when the user asks about their number, life path or lucky colour/day/stone. It is NOT astrology and shares nothing with the chart tools: for a birth chart use get_janam_kundali, for a birth star use get_birth_details. Read-only deterministic arithmetic over the classical Chaldean number table -- no ephemeris is touched, and the result's Source line says so. No writes, no auth, at least 30 requests/min/IP per server instance. Birth time and place are not used, so none is asked for.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Date of birth as YYYY-MM-DD, e.g. 1992-03-14. Must be a real calendar date. Birth time, timezone and place have no effect in numerology and are not accepted."
    },
    "name": {
      "description": "Full name in Latin letters, e.g. \"Rahul Sharma\" -- it must contain at least one A-Z letter. Optional: supply it to add the Chaldean name number and its meaning; omit and only the date-derived numbers are returned.",
      "type": "string",
      "minLength": 1,
      "maxLength": 120
    }
  },
  "required": [
    "birth_date"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_love_compatibility(name_a, name_b)

Returns a light-hearted name-compatibility score between two people from Pythagorean numerology: each name reduces to a digit 1-9 (any master number 11/22/33 is reported alongside), the pair maps to a 0-100 score, and a short fixed reading and band come with it. Use this ONLY for entertainment, and say so when presenting it. It uses names, not birth data, so it can say nothing real about a relationship: for genuine marriage matching call get_kundli_match, which scores both birth charts on the Ashtakoot system. Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no birth details, no writes, no auth, at least 30 requests/min/IP per server instance.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "name_a": {
      "type": "string",
      "minLength": 1,
      "maxLength": 80,
      "description": "First person's name in Latin letters, e.g. \"Rahul\". Must contain at least one A-Z letter; digits and punctuation are ignored when scoring."
    },
    "name_b": {
      "type": "string",
      "minLength": 1,
      "maxLength": 80,
      "description": "Second person's name in Latin letters, e.g. \"Priya\". Same rules as name_a."
    }
  },
  "required": [
    "name_a",
    "name_b"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_mobile_numerology(mobile_number)

Returns a numerological reading of a mobile or landline number: the extracted digit string, the digit total, the single 1-9 number it reduces to, the overall vibe that reduced number carries, and the traditional meaning of each distinct digit present. Use this for 'is my phone number lucky' style questions, or when choosing between candidate numbers. It reads a number string only -- nothing about the person -- so for anything tied to a birth date use get_numerology. Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no network lookup of the number, no writes, no auth, at least 30 requests/min/IP per server instance.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "mobile_number": {
      "type": "string",
      "minLength": 1,
      "maxLength": 32,
      "description": "Phone number in any format -- \"+91 98765-43210\", \"9876543210\" and \"(020) 7946 0958\" all work, since +, spaces, hyphens and brackets are stripped. Must contain at least one non-zero digit."
    }
  },
  "required": [
    "mobile_number"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_birth_details(birth_date, birth_time, place, latitude, longitude, ...)

Returns just the identity fields of a Vedic birth chart: the Moon's janma nakshatra (birth star) with its 1-27 number and pada, the janma rashi (moon sign) with its classical lord and the house it occupies, the lagna (ascendant) with degree in sign, nakshatra, pada and lord, and the navamsa (D9) lagna with its lord. Use this for the common single questions -- 'what is my nakshatra / rashi / lagna' -- and to fetch janma_nakshatra and janma_rashi values that get_muhurta_timings accepts. It returns NO planet table, no yogas and no dasha: for those call get_janam_kundali (whole chart) or get_dasha_periods (dasha only). Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_dasha_periods(birth_date, birth_time, place, latitude, longitude, ...)

Returns the Vimshottari dasha timetable for one birth chart: the mahadasha, antardasha and pratyantardasha running right now with their end dates, the mahadasha in force at birth with its unexpired balance in years-months-days, and the full nine-mahadasha lifetime timeline with a start and end date per period. For a chart cast at the present moment no dasha has elapsed yet, so the birth mahadasha stands in and the result is flagged is_birth_fallback -- do not report it as a separately computed current period. Use this for 'which dasha am I in', 'when does my Saturn mahadasha start' and any life-period timeline question. It returns dates only -- no interpretation of what a period brings. For the planet placements those dasha lords sit in, call get_janam_kundali. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa) from the Moon's birth nakshatra; no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. Dates shift with birth-time accuracy.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_upapada_arudha(birth_date, birth_time, place, latitude, longitude, ...)

Returns the Jaimini layer of one birth chart: the upapada lagna (UL, the classical marriage anchor) with its sign, lord and cited reading, all twelve arudha padas (A1-A12) with sign and life domain, the eight charakarakas (Atmakaraka, Amatyakaraka and the rest) with the graha holding each, and the karakamsha lagna. The result also lists the classical texts the upapada reading is cited from. Use this only when Jaimini terms are asked for by name -- upapada, arudha, charakaraka, karakamsha -- or for marriage questions read the Jaimini way. The Parashari layer (grahas, houses, dasha, yogas) is in get_janam_kundali; get_kundli_match is the tool for scoring two charts against each other. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. If the engine cannot attach the Jaimini layer the result comes back with partial: true rather than with invented values.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "birth_date": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
    },
    "birth_time": {
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$",
      "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    }
  },
  "required": [
    "birth_date",
    "birth_time"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}
🟢get_transits(date, time, place, latitude, longitude, ...)

Returns where the nine grahas actually are at a moment in time (gochar / transit chart), for a place: each graha's sidereal sign, degree within the sign, nakshatra, pada, retrograde flag, dignity and house from the transit ascendant, plus the transit lagna itself. Defaults to right now at that place. Pass the optional `natal` birth details and the result ALSO counts each transiting graha's whole-sign house from the natal Moon (chandra lagna) -- the frame classical gochar is read in. Use this for 'where is Saturn/Jupiter right now' and 'what is transiting my moon sign' questions. It answers for ONE moment only and returns no ingress, retrograde-station or sign-change dates -- do not scan it across many dates to find them. For the birth chart itself use get_janam_kundali; for dated Saturn phases use get_sade_sati, the one tool here that returns transit date ranges. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all chart tools -- and a call carrying `natal` costs TWO of those, since it computes the natal chart as well. It returns COMPUTED POSITIONS ONLY -- no forecast, horoscope or interpretation text is produced.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "date": {
      "description": "Date of the transit chart, YYYY-MM-DD, years 1200-2400. Omit for today at the given place. A past or future date gives the positions for that single day.",
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
    },
    "time": {
      "description": "Local clock time of the transit chart, HH:MM 24-hour (00:00-23:59). Omit for the current time at the given place. It matters most for the Moon (about 13 degrees a day) and for the transit lagna (a full sign every two hours); the slow grahas barely move within a day.",
      "type": "string",
      "pattern": "^\\d{2}:\\d{2}$"
    },
    "place": {
      "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
      "type": "string",
      "minLength": 1,
      "maxLength": 160
    },
    "latitude": {
      "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
      "type": "number",
      "minimum": -90,
      "maximum": 90
    },
    "longitude": {
      "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
      "type": "number",
      "minimum": -180,
      "maximum": 180
    },
    "timezone": {
      "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    },
    "natal": {
      "description": "Optional birth details of the person the transits are being read for: birth_date, birth_time and a place (or latitude + longitude + timezone). Supply them to add the gochar_from_natal_moon block. Omit and only the sky positions are returned.",
      "type": "object",
      "properties": {
        "birth_date": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected)."
        },
        "birth_time": {
          "type": "string",
          "pattern": "^\\d{2}:\\d{2}$",
          "description": "Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart."
        },
        "place": {
          "description": "Place as free text, \"City, State, Country\" -- e.g. \"Jaipur, Rajasthan, India\". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead.",
          "type": "string",
          "minLength": 1,
          "maxLength": 160
        },
        "latitude": {
          "description": "Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too.",
          "type": "number",
          "minimum": -90,
          "maximum": 90
        },
        "longitude": {
          "description": "Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted.",
          "type": "number",
          "minimum": -180,
          "maximum": 180
        },
        "timezone": {
          "description": "IANA timezone name, e.g. \"Asia/Kolkata\" or \"America/New_York\" (never an offset like \"+05:30\"). Required when latitude/longitude are used; ignored when `place` is given.",
          "type": "string",
          "minLength": 1,
          "maxLength": 64
        }
      },
      "required": [
        "birth_date",
        "birth_time"
      ]
    }
  },
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Comunidad

Califica este servidor

Evidencia

Observaciones recientes

verificadoversión no registrada17 herramientas
verificadoversión no registrada17 herramientas