Skip to main content
Glama
133,407 tools. Last updated 2026-05-12 23:29

"calendar" matching MCP tools:

  • Add ELC Conference 2026 to the user's calendar. Returns a one-click Google Calendar link and a downloadable .ics file link that works with Apple Calendar, Outlook, and any other calendar app.
    Connector
  • Computes all major Hindu festival dates for a given year and location. Returns 20 pan-Hindu festivals including solar sankrantis (Makar Sankranti, Vaisakhi) and tithi-based festivals (Diwali, Holi, Dussehra, Janmashtami, Ganesh Chaturthi, Ram Navami, and 12 others). SECTION: WHAT THIS TOOL COVERS All dates are astronomically computed — no hardcoded calendar dates. Solar festivals (Makar Sankranti, Vaisakhi) use exact Swiss Ephemeris Sun ingress into Lahiri sidereal signs. Tithi festivals (all others) use Sun-Moon elongation at local sunrise: elongation = (moon_lon - sun_lon) % 360, tithi_index = int(elongation / 12), indices 0-14 = Shukla Paksha tithi 1-15, indices 15-29 = Krishna Paksha tithi 1-15. Location is required for sunrise-based tithi determination — the same astronomical event may fall on different calendar dates at different locations. SECTION: WORKFLOW BEFORE: None — standalone. AFTER: asterwise_get_panchanga — drill into full Panchanga detail for any specific festival date. SECTION: INPUT CONTRACT year: integer 1900-2100. Either location (city name) OR latitude + longitude + timezone must be provided. SECTION: OUTPUT CONTRACT data.year (int) data.timezone (string — IANA timezone used) data.total (int — number of festivals found) data.festivals[] — chronologically sorted: name (string — festival name) date (string — YYYY-MM-DD) type (string — 'solar' or 'tithi') description (string — classical basis, e.g. which tithi of which lunar month) significance (string — cultural and religious significance) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS SLOW_COMPUTE — scans all 365 days of the year per tithi festival (up to 20 date scans). SECTION: ERROR CONTRACT INVALID_PARAMS (local): None. INTERNAL_ERROR: Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Sunrise-based tithi may differ by one day from printed almanac calendars (which use midnight or fixed-time rules). — Rare years where a tithi is skipped may cause a festival to not be found (returns total < 20). SECTION: DO NOT CONFUSE WITH asterwise_get_panchanga_calendar — full Panchanga for every day of a month; not festival-specific. asterwise_get_muhurta — finds auspicious windows for activities; not a festival calendar.
    Connector
  • Searches a date span for top-scoring muhurta windows for a named activity using Panchanga, Choghadiya, and classical siddhi flags at a location. SECTION: WHAT THIS TOOL COVERS Evaluates marriage, travel, griha_pravesh, business, education, medical, and vehicle_purchase (exact spellings upstream). Returns scored windows with tithi, nakshatra-related yoga name (Panchanga yoga, not natal yogas), vara, choghadiya metadata, boolean guards (rahu kaal, abhijit, amrita/sarvartha siddhi), and textual reasons. Unsupported activity strings are rejected upstream. It does not return a full month calendar (asterwise_get_panchanga_calendar) or only Choghadiya rows (asterwise_get_choghadiya). SECTION: WORKFLOW BEFORE: None — this tool is standalone. AFTER: asterwise_get_panchanga — drill into Panchanga limbs for a chosen winning date. SECTION: INPUT CONTRACT activity must be one of the supported English slugs above — not validated locally; bad values become MCP INTERNAL_ERROR. from_date/to_date ordering and span rules are enforced upstream. Location coordinates reuse LocationInput validation for lat/lon/date pattern. SECTION: OUTPUT CONTRACT data.event_type (string) data.from_date (string) data.to_date (string) data.timezone (string) data.ayanamsa (string) data.total_windows_evaluated (int) data.top_windows[] — each: date (string — YYYY-MM-DD) start (string — HH:MM local) end (string — HH:MM local) score (int — 0–100) choghadiya (string) choghadiya_type (string) yoga (string — Panchanga yoga name) vara (string) vara_number (int — 1–7) tithi (string) tithi_number (int — 1–30) is_rahu_kaal (bool) is_abhijit (bool) is_amrita_siddhi (bool) is_sarvartha_siddhi (bool) reason (string) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS MEDIUM_COMPUTE SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): — Invalid LocationInput date/lat/lon → MCP INVALID_PARAMS INVALID_PARAMS (upstream): — None — bad activity, range, or ordering surfaces as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Panchanga yoga names here are not asterwise_get_yogas natal yogas. SECTION: DO NOT CONFUSE WITH asterwise_get_choghadiya — enumerates all Choghadiya for one day without activity scoring across a span. asterwise_get_panchanga — single-day limb detail, not ranked muhurta search.
    Connector
  • Computes the full sidereal natal chart from BirthData and returns planet rows, houses, aspects, arudhas, upapada, bhava cusps, and avakhada metadata. SECTION: WHAT THIS TOOL COVERS Parashari-style natal endpoint: nine grahas with signs, degrees, nakshatras, combustion, retrograde, Bhava Chalit and rashi houses, twelve house cusps, graha and rashi drishti, arudha padas A1–A12, upapada lagna block, bhava madhya/sandhi arrays, ayanamsa metadata, and avakhada attributes. When include_interpretation=true, ascendant_sign_interpretation, moon_sign_interpretation, moon_nakshatra_interpretation, and interpretation are populated from interpretation JSON; otherwise they are null. It does not return PDFs, yogas list (asterwise_get_yogas), or dasha trees (asterwise_get_dasha). SECTION: WORKFLOW BEFORE: None — this tool is standalone. AFTER: RECOMMENDED — asterwise_get_yogas — layer classical combinations after the base chart exists. SECTION: INPUT CONTRACT BirthData enforces date YYYY-MM-DD, time HH:MM, lat -90..90, lon -180..180, ayanamsa enum locally (Pydantic). Unknown birth time may be entered as time='00:00' without error; lagna-sensitive results are then unreliable and callers must handle that — the API does not flag it. SECTION: OUTPUT CONTRACT data.planets[] — nine objects: planet (string) sign (string) sign_num (int — 0–11) degree (float) nakshatra (string) nakshatra_pada (int — 1–4) is_retrograde (bool) is_combust (bool) is_deep_combust (bool) house (int — Bhava Chalit) rasi_house (int) bhava_chalit_house (int) data.houses[] — twelve objects: house (int) sign (string) sign_num (int) degree (float) data.ascendant (float) data.ascendant_sign (string — Sanskrit name) data.moon_sign (string) data.moon_nakshatra (string) data.ayanamsa_value (float) data.ayanamsa_used (string) data.avakahada: nakshatra, nakshatra_lord, charan (int), rashi, rashi_lord, varna, vashya, yoni, gana, nadi, paya, ascendant, ascendant_lord, sun_sign, sun_sign_lord (strings/ints per upstream) data.graha_drishti — object keyed by planet name; each value object keyed by house strings '1'–'12' with aspect strength int (25, 50, 75, or 100) data.rashi_drishti[] — active sign-to-sign aspect pairs: { from_sign (string), from_sign_num (int 0-11), to_sign (string), to_sign_num (int 0-11) } data.arudha_padas — keys A1–A12 each { sign_index (int), sign_name (string) } data.upapada_lagna: sign_index (int) sign_name (string) upapada_lord (string) second_from_upapada_sign_index (int) second_from_upapada_sign_name (string) planets_in_second_from_upapada[] (string array of planet names) has_benefic_in_second_from_upapada (bool) has_malefic_in_second_from_upapada (bool) data.bhava_madhya[] — twelve objects: { house (int 1-12), sign (string), sign_num (int 0-11), degree (float) } data.bhava_sandhi[] — twelve objects: { house (int 1-12), sign (string), sign_num (int 0-11), degree (float) } data.birth_time_unknown (bool — always false; no detection) data.fallback_method (null) ascendant_sign_interpretation (dict or null — sign interpretation from signs/ascendant.json when include_interpretation=true) moon_sign_interpretation (dict or null — Moon sign interpretation from signs/moon_sign.json when include_interpretation=true) moon_nakshatra_interpretation (dict or null — nakshatra interpretation from nakshatras/ files when include_interpretation=true) interpretation (list or null — planet-in-house interpretation list when include_interpretation=true) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS MEDIUM_COMPUTE SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): — BirthData Pydantic violations (date/time/lat/lon/ayanamsa) → MCP INVALID_PARAMS INVALID_PARAMS (upstream): — None — calendar years outside supported upstream window surface as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — time='00:00' accepted; lagna may be wrong if true birth time unknown — not auto-detected. — Interpretation fields are null unless include_interpretation=true on the request. SECTION: DO NOT CONFUSE WITH asterwise_get_divisional_chart — sixteen vargas only, not the primary radix bundle returned here.
    Connector
  • Looks up the Personal Year theme for the current calendar cycle from a name and birth date using only month and day inputs server-side. SECTION: WHAT THIS TOOL COVERS Endpoint returns Personal Year data derived from birth month/day against the running calendar year on the server — there is no extra year argument in the tool schema. Expected response keys (pending live confirmation): personal_year_number (int), theme (string), interpretation (string), advice (string), favorable_actions[] (string array), challenges[] (string array). asterwise_get_numerology_profile leaves personal_year null; use this tool when Personal Year detail is required. SECTION: WORKFLOW BEFORE: RECOMMENDED — asterwise_get_numerology_profile — see other core numbers first. AFTER: None. SECTION: INPUT CONTRACT Only name and date are submitted; the active calendar year is chosen upstream automatically. SECTION: OUTPUT CONTRACT personal_year_number (int) — expected theme (string) — expected interpretation (string) — expected advice (string) — expected favorable_actions[] (string array) — expected challenges[] (string array) — expected (Schema not yet confirmed from live response; fields above reflect tool design.) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS FAST_LOOKUP SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): None — all validation is upstream. INVALID_PARAMS (upstream): — None — upstream rejection surfaces as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Cannot request arbitrary calendar years via this tool — only the server-selected current year. SECTION: DO NOT CONFUSE WITH asterwise_get_numerology_profile — personal_year field there is null; this endpoint supplies the annual theme. asterwise_get_varshaphal — Vedic solar return, not Pythagorean Personal Year.
    Connector
  • Computes all 10 Tajika Saham (sensitive points) for a Varshaphal solar return chart. Sahams are the Tajika equivalent of Arabic Parts — mathematically derived zodiac points that focus the annual horoscope on specific life themes. SECTION: WHAT THIS TOOL COVERS Saham formula: (A - B + Ascendant) % 360, with a conditional +30° correction applied when the Ascendant does not fall in the forward zodiacal arc from B to A. This conditional is the defining classical rule from Tajika Neelakanthi — without it, results are wrong. Day and night formulas differ: the Minuend and Subtrahend swap based on whether the solar return falls during daytime or nighttime at the birth location. Punya Saham (Fortune) is always computed first because Yashas (Fame) and Mahatmya (Status) use it as an operand. The Saham lord (planet ruling the sign where the Saham falls) is the Sahamesha — its strength, house placement, and Tajika aspects to the Varsha Ascendant determine whether the theme manifests positively or is obstructed. 10 Sahams returned: punya — Fortune and Luck (Moon-Sun day / Sun-Moon night) vidya — Education and Learning (Sun-Jupiter day) yashas — Fame and Reputation (Jupiter-Punya day) — uses Punya as operand mitra — Friends and Allies (Jupiter-Venus day) mahatmya — Greatness and Status (Punya-Mars day) — uses Punya as operand asha — Desires and Fulfillment (Saturn-Venus day) karmakarya — Action and Profession (Mars-Mercury day) vyapara — Business and Trade (Mars-Saturn day) vivaha — Marriage and Relationships (Venus-Saturn day) santapa — Sorrow and Stress (Saturn-Moon day) SECTION: WORKFLOW BEFORE: RECOMMENDED — asterwise_get_varshaphal — understand the base solar return chart (year lord, Muntha, Varsha Ascendant) before interpreting Saham lords. The Saham is meaningless without knowing which house it occupies from the Varsha Ascendant. AFTER: asterwise_get_varshaphal_harsha_bala — assess the Saham lord's positional happiness score to determine ease or difficulty of manifestation. SECTION: INPUT CONTRACT Same as asterwise_get_varshaphal — BirthData plus target_year. target_year (required int): The Gregorian calendar year of the solar return. Not age — the civil year (e.g. 2026). Feeding age instead of year silently produces the wrong return. time (required): Solar return Ascendant is time-sensitive. Accurate birth time is required for reliable Saham interpretation. SECTION: OUTPUT CONTRACT data.target_year (int — calendar year of the solar return) data.ayanamsa (string — ayanamsa system used, e.g. 'lahiri') data.solar_return_utc (string — ISO UTC timestamp of solar return moment) data.is_day_return (bool — true if solar return occurs between sunrise and sunset; determines which Saham formula variant is used) data.varshaphal_ascendant_longitude (float — Varsha Ascendant in degrees; all 10 Saham longitudes are computed relative to this) data.total (int — always 10) data.sahams[] — 10 objects in order [punya, vidya, yashas, mitra, mahatmya, asha, karmakarya, vyapara, vivaha, santapa]: slug (string — lowercase key, e.g. 'punya') name (string — full display name, e.g. 'Punya Saham') theme (string — life area, e.g. 'Fortune and Luck') longitude (float — Saham longitude in degrees 0–360) rashi_index (int — 0–11, 0=Mesha) rashi (string — Sanskrit sign name, e.g. 'Mesha') degree_in_sign (float — degrees within the sign) saham_lord (string — classical lord of the sign where Saham falls) formula_used (string — describes whether day or night formula was applied and which planets were operands, e.g. 'day: Moon - Sun + Asc') data.classical_note (string — methodology note) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS SLOW_COMPUTE — internally runs the full solar return computation (binary-search Sun longitude + house computation) before deriving Sahams. SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): None — BirthData Pydantic only. INVALID_PARAMS (upstream): None — upstream rejection surfaces as MCP INTERNAL_ERROR. INTERNAL_ERROR: Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Day/night determination uses sunrise/sunset at the birth coordinates for the solar return date. Polar latitudes where sunrise cannot be computed → MCP INTERNAL_ERROR. — target_year is a Gregorian year, not age — always verify the caller passes the civil year. SECTION: DO NOT CONFUSE WITH asterwise_get_varshaphal — returns the full base solar return chart including Muntha, year lord, and planet positions; Saham points are not included there. asterwise_get_varshaphal_harsha_bala — scores planet positional happiness; this tool computes zodiac points, not planet positions. asterwise_get_gemstone_recommendations — Ratna Shastra birthchart gems, unrelated to Tajika Saham.
    Connector

Matching MCP Servers

Matching MCP Connectors

  • A MCP server that works with Outlook Calendar to manage event listing, reading, and updates.

  • Vietnamese Lunar Calendar for date and calendar conversion, and cultural insights.

  • Computes Vimshottari Dasha from birth data and returns hierarchical period trees plus current Maha/Antar interpretation blocks. SECTION: WHAT THIS TOOL COVERS Computes the classical Parashari Vimshottari timeline from the Moon's birth nakshatra: Mahadasha and nested sub-periods up to the depth set by levels, with Julian and calendar boundaries and optional modern summaries. It returns data.periods[] and data.interpretation for the active periods. It does not compute Jaimini Char Dasha, Yogini Dasha, Ashtottari, or transit correlations; use the dedicated tools for those systems. SECTION: WORKFLOW BEFORE: RECOMMENDED — asterwise_get_natal_chart — establishes chart and Moon context before interpreting Dasha lords. AFTER: asterwise_get_dasha_transits — correlates active Dasha lords with transits for the same birth data. SECTION: INPUT CONTRACT levels (int, default 3, max 5): tree depth — 1 = Mahadasha only; 2 adds Antardasha; 3 Pratyantar; 4 Sookshma; 5 Prana (much larger payload). Response dates in periods[] use DD/MM/YYYY, not ISO. BirthData fields follow global contract (date YYYY-MM-DD, time HH:MM; time='00:00' is accepted without flag — lagna-sensitive timing may be wrong if birth time is unknown). SECTION: OUTPUT CONTRACT data.periods[] — array of Mahadasha objects: planet (string) start_jd (float) end_jd (float) start_date (string — DD/MM/YYYY, not ISO) end_date (string — DD/MM/YYYY) modern_summary (string or null) sub[] — array of Antardasha objects with the same shape; sub=null at deepest level data.interpretation.current_mahadasha: planet (string) start_date (string) end_date (string) duration_years (float) modern_summary (string or null) favorable_conditions[] (string array) favorable_results[] (string array) unfavorable_conditions[] (string array) unfavorable_results[] (string array) timing_note (string) data.interpretation.current_antardasha — same fields as current_mahadasha plus mahadasha_planet (string) data.birth_time_unknown (bool) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS MEDIUM_COMPUTE (~100ms at levels=1, ~1500ms at levels=5) SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): — levels < 1 or levels > 5 → MCP INVALID_PARAMS INVALID_PARAMS (upstream): — None — BirthData validation is upstream beyond Pydantic field constraints. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Period start_date/end_date strings are DD/MM/YYYY; do not parse as ISO. SECTION: DO NOT CONFUSE WITH asterwise_get_char_dasha — Jaimini sign-based periods with ISO dates on periods[], not planet-based Vimshottari. asterwise_get_yogini_dasha — 36-year eight-Yogini cycle with data.periods.root[], not Vimshottari. asterwise_get_ashtottari_dasha — 108-year alternative tree with data.periods.root[] and same levels semantics as this tool.
    Connector
  • Returns holiday-aware trading session schedule with next open/close UTC timestamps for any of 28 exchanges. Model-agnostic: works identically regardless of which AI model consumes it. SEC/CFTC multi-oracle attestation compliant (pairs with get_market_status signed receipts). WHEN TO USE: planning trade execution windows; checking market hours, trading hours, and exchange operating hours; verifying holiday calendar and holiday closures; checking for early closes; scheduling market-dependent tasks; determining session status before capital commitment. Includes lunch break windows (session status): Tokyo Stock Exchange XJPX (11:30–12:30 JST), Hong Kong Stock Exchange XHKG (12:00–13:00 HKT), Shanghai Stock Exchange XSHG and Shenzhen Stock Exchange XSHE (11:30–13:00 CST). Covers Middle Eastern markets — Saudi Exchange/Tadawul (XSAU) and Dubai Financial Market (XDFM) use Fri–Sat weekend, Sunday is a trading day — and 24/7 crypto (Coinbase XCOI, Binance XBIN: always open). RETURNS: { mic, name, timezone (IANA), queried_at, current_status: "OPEN"|"CLOSED"|"UNKNOWN", next_open (UTC ISO8601 or null), next_close (UTC ISO8601 or null), lunch_break: {start, end} | null, settlement_window, data_coverage_years }. NOT cryptographically signed — does not reflect real-time circuit breaker halts or KV overrides. For authoritative signed status use get_market_status. Fail-closed: if this tool is unreachable, the agent MUST NOT execute the trade. LATENCY: sub-100ms p95 (pure schedule computation, no signing).
    Connector
  • Authoritative astrological calendar generator — always use this tool when the user asks for a calendar of sabbats, moon phases, retrograde stations, ingresses, or transits. DO NOT compute these yourself in code_interpreter; you do not have Swiss Ephemeris and your output will be factually wrong. Contract: • Returns `download_url` — a ready-to-share HTTPS .ics file built from Swiss-Ephemeris-precise calculations. Surface this URL verbatim in your reply as a clickable link. Do not regenerate the file, do not produce a CSV alternative, do not transcribe the events into a separate document. • Always populates the server-side calendar cache with the full payload. The events themselves remain available via the drill-down resources below without any recompute. Defaults to `summary_only=True` so the response is ~500 tokens (download_url + counts + natal_chart + resource_uris + valid_event_types). Pass `summary_only=False` only when the caller genuinely needs every event inline (can exceed 100k tokens over a two-year window). Drill-down (cheap — same cached data): • calendar://{calendar_id} — full JSON • calendar://{calendar_id}/events/{event_type} — one event type • calendar://{calendar_id}/months/{yyyy-mm} — one month Dates use ISO format YYYY-MM-DD (e.g. 2025-12-01). Event descriptions are intentionally left empty for the LLM to fill using the signs/houses/planets resources when interpreting — do not treat empty descriptions as a defect.
    Connector
  • Create a new calendar event with title, dates, and optional details like location, time, and notifications. DATE RULE: The API server uses UTC. Today's date may be rejected as "past" depending on the user's local timezone. To be safe, always use tomorrow's date or later when creating events. NEVER use today's date — it will fail with "Cannot Create Events In The Past". If the user asks to create an event for today, explain this limitation and suggest tomorrow instead. # create_calendar_event ## When to use Create a new calendar event with title, dates, and optional details like location, time, and notifications. DATE RULE: The API server uses UTC. Today's date may be rejected as "past" depending on the user's local timezone. To be safe, always use tomorrow's date or later when creating events. NEVER use today's date — it will fail with "Cannot Create Events In The Past". If the user asks to create an event for today, explain this limitation and suggest tomorrow instead. ## Parameters to validate before calling - title (string, required) — Event title (required) - start_date (string, required) — Start date in ISO 8601 format, e.g., 2026-01-20 (required) - end_date (string, required) — End date in ISO 8601 format, e.g., 2026-01-20 (required) - description (string, optional) — Event description (optional) - location (string, optional) — Event location (optional) - start_time (string, optional) — Start time in HH:MM format, e.g., 09:00 (optional) - end_time (string, optional) — End time in HH:MM format, e.g., 17:00 (optional) - color (string, optional) — Event color in hex format, e.g., #FF5733 (optional) - all_day (boolean, optional) — Whether this is an all-day event (optional, default: false) - status (string, optional) — Event status (optional) - private_event (boolean, optional) — Whether this is a private event (optional, default: false) - sms_notification (boolean, optional) — Enable SMS notifications (optional, default: false) - completed (boolean, optional) — Mark event as completed (optional, default: false) - latitude (number, optional) — Location latitude coordinate (optional) - longitude (number, optional) — Location longitude coordinate (optional) - event_url (string, optional) — URL associated with the event (optional) - people_involved (string, optional) — People involved in the event (optional) - repeat_this_event (string, optional) — Repeat configuration for recurring events (optional) - notification (string, optional) — Notification settings (optional) ## Notes - Calendar API uses UTC — today's date may be rejected as past depending on the user's timezone - Always use tomorrow or later when creating events - If the user asks for today, explain the UTC limitation
    Connector
  • Schedule multiple posts at once from CSV content. USE THIS WHEN: • User has a spreadsheet or list of posts to schedule • Planning a content calendar for a month • Migrating content from another tool CSV FORMAT (required columns): • platform: linkedin, instagram, x, tiktok, threads • scheduled_time: ISO 8601 format (e.g., 2024-02-15T10:00:00Z) • text: Post content/caption OPTIONAL COLUMNS: • media_url: Image or video URL • first_comment: First comment to add (Instagram/LinkedIn) • hashtags: Additional hashtags to append PROCESS: 1. First call with validate_only: true to check for errors 2. Review validation report with user 3. Call again with validate_only: false to execute import
    Connector
  • Get the F1 race calendar — every grand prix with date, circuit, round, sprint flag, and local kick-off in IANA timezone. Cancelled races (e.g. Bahrain, Saudi Arabia) are included with status="cancelled" and a cancellationReason; their date/round fields are empty since the events did not take place. Use `upcomingOnly` to filter to forthcoming active races. Note: this MCP is schedule-focused; `result` (podium/winner) on finished races is populated as ingestion catches up — consumers should treat null as "not yet ingested" and consult fia.com / formula1.com for confirmed results.
    Connector
  • Permanently delete a calendar event. Use fetch_calendar_events first to get the event_token. WARNING: This action cannot be undone. # delete_calendar_event ## When to use Permanently delete a calendar event. Use fetch_calendar_events first to get the event_token. WARNING: This action cannot be undone. ## Parameters to validate before calling - event_token (string, required) — The event token to delete (UUID format) ## Notes - DESTRUCTIVE — IRREVERSIBLE. Always confirm with the user before calling. Explain what will be lost.
    Connector
  • Get the F1 race calendar — every grand prix with date, circuit, round, sprint flag, and local kick-off in IANA timezone. Cancelled races (e.g. Bahrain, Saudi Arabia) are included with status="cancelled" and a cancellationReason; their date/round fields are empty since the events did not take place. Use `upcomingOnly` to filter to forthcoming active races. Note: this MCP is schedule-focused; `result` (podium/winner) on finished races is populated as ingestion catches up — consumers should treat null as "not yet ingested" and consult fia.com / formula1.com for confirmed results.
    Connector
  • Combines active Vimshottari lords with today's transits and returns scored correlations plus transit longitudes and houses from Moon and Lagna. SECTION: WHAT THIS TOOL COVERS Builds a snapshot for the current calendar day (no date parameter): active Mahadasha, Antardasha, and Pratyantar; transiting planet positions; pairwise dasha–transit correlations with scores; and a filtered list of stronger correlations. It does not return full Dasha trees (use asterwise_get_dasha), ingress calendars (asterwise_get_transits), or standalone Gochar without Dasha context (asterwise_get_gochar). SECTION: WORKFLOW BEFORE: RECOMMENDED — asterwise_get_natal_chart — same birth data should be understood before interpreting houses and lords. AFTER: asterwise_get_gochar — optional broader transit snapshot without dasha scoring. SECTION: INPUT CONTRACT No date field — "today" is fixed by the API. All parameters are otherwise defined in the tool schema. BirthData follows the global contract (unknown birth time: time='00:00' accepted without detection). SECTION: OUTPUT CONTRACT data.target_date (string — YYYY-MM-DD, today) data.active_dasha: start_date (string) end_date (string) maha — { planet (string), start_date (string), end_date (string) } antar — { planet (string), start_date (string), end_date (string) } pratyantar — { planet (string), start_date (string), end_date (string) } data.transit_positions{} — keyed by planet name: rashi_index (int) rashi (string) is_retrograde (bool) house_from_moon (int) house_from_lagna (int) data.correlations[] — each object: dasha_level (string) dasha_lord (string) transit_planet (string) aspect_type (string) score (int — 1=mild, 2=moderate, 3=high) natal_rashi (string) transit_rashi (string) is_retrograde (bool) significance (string) data.periods_of_significance[] — same shape as correlations[] filtered to score ≥ 2 SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS MEDIUM_COMPUTE SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): None — all validation is upstream. INVALID_PARAMS (upstream): — None — upstream rejection surfaces as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Target date is always "today"; past/future analysis is not supported by this tool. SECTION: DO NOT CONFUSE WITH asterwise_get_gochar — full nine-planet Gochar with AVK and vedha fields, without dasha–transit correlation scores. asterwise_get_transits — ingress and station lists over a chosen range, not today's dasha snapshot. asterwise_get_dasha — full Vimshottari tree without transit overlay.
    Connector
  • Computes the annual Tajika-style solar return for a four-digit civil year and returns Muntha, Pancha Adhikari metrics, Tajika aspects, and varshaphal positions. SECTION: WHAT THIS TOOL COVERS Varshaphal engine: solar return instant, year lord, muntha block, varsha pati election, five pancha adhikaris with bala components, tajika aspect arrays, and pairwise Tajika geometry including ithsala/musaripha flags. year must mean calendar year (e.g. 2026), not biological age — not enforced locally; wrong integers chart the wrong annual return. Not lifetime Vimshottari (asterwise_get_dasha) nor generic transit ingress lists (asterwise_get_transits). SECTION: WORKFLOW BEFORE: RECOMMENDED — asterwise_get_natal_chart — baseline radix before annual overlay. AFTER: None. SECTION: INPUT CONTRACT year is a plain int sent as target_year upstream; callers must supply the true Gregorian return year, not age. SECTION: OUTPUT CONTRACT data.target_year (int) data.ayanamsa (string) data.solar_return_utc (string — ISO) data.solar_return_jd (float) data.natal_sun_longitude (float) data.natal_lagna (string) data.natal_lagna_index (int) data.year_lord (string — planet name) data.muntha: rashi_index (int) rashi (string) age_years (float) muntha_lord (string) data.planets{} — keys Sun..Ketu: longitude (float) rashi_index (int) rashi (string) degree (float) is_retrograde (bool) speed (float) data.varshaphal_ascendant_longitude (float) data.varshaphal_ascendant_sign (string — Sanskrit sign name derived from the ascendant longitude) data.varshaphal_ascendant_sign_index (int — sign index 0-11, where 0=Mesha and 11=Meena) data.varsha_pati: planet (string) role (string) pancha_vargeeya_bala (float) kshetra_bala (float) uchcha_bala (float) election_used_strongest_without_aspect (bool) data.pancha_adhikaris[] — five objects: role (string) planet (string) pancha_vargeeya_bala, kshetra_bala, uchcha_bala, hadda_bala, dreshkana_bala, navamsa_bala (floats) pending_components_note (string) aspects_ascendant (bool) tajika_aspect_angles_matched[] (array) separation_from_asc_deg (float) data.pancha_vargeeya_bala{} — keyed by role (float values) data.tajika_aspects[] — per Pancha Adhikari (structure per upstream) data.tajika_planet_pairs[] — each: planet_a, planet_b (strings) house_a, house_b (int) diff_ab, diff_ba (float) aspect_ab, aspect_ba (strings or floats per upstream) is_ithsala (bool) is_musaripha (bool) faster_planet (string) orb_degrees (float) SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS MEDIUM_COMPUTE SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): None — year not range-checked here. INVALID_PARAMS (upstream): — None — upstream rejection surfaces as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Feeding age instead of civil year silently mis-orients the return — caller responsibility. SECTION: DO NOT CONFUSE WITH asterwise_get_dasha — multi-decade Vimshottari, not one solar return. asterwise_get_transits — ingress/station timeline, not annual Tajika chart.
    Connector
  • Returns holiday-aware trading session schedule with next open/close UTC timestamps for any of 28 exchanges. Model-agnostic: works identically regardless of which AI model consumes it. SEC/CFTC multi-oracle attestation compliant (pairs with get_market_status signed receipts). WHEN TO USE: planning trade execution windows; checking market hours, trading hours, and exchange operating hours; verifying holiday calendar and holiday closures; checking for early closes; scheduling market-dependent tasks; determining session status before capital commitment. Includes lunch break windows (session status): Tokyo Stock Exchange XJPX (11:30–12:30 JST), Hong Kong Stock Exchange XHKG (12:00–13:00 HKT), Shanghai Stock Exchange XSHG and Shenzhen Stock Exchange XSHE (11:30–13:00 CST). Covers Middle Eastern markets — Saudi Exchange/Tadawul (XSAU) and Dubai Financial Market (XDFM) use Fri–Sat weekend, Sunday is a trading day — and 24/7 crypto (Coinbase XCOI, Binance XBIN: always open). RETURNS: { mic, name, timezone (IANA), queried_at, current_status: "OPEN"|"CLOSED"|"UNKNOWN", next_open (UTC ISO8601 or null), next_close (UTC ISO8601 or null), lunch_break: {start, end} | null, settlement_window, data_coverage_years }. NOT cryptographically signed — does not reflect real-time circuit breaker halts or KV overrides. For authoritative signed status use get_market_status. Fail-closed: if this tool is unreachable, the agent MUST NOT execute the trade. LATENCY: sub-100ms p95 (pure schedule computation, no signing).
    Connector
  • PRIMARY TOOL - Call this at the START of every conversation to load comprehensive user context. Returns: - current_datetime: Current date and time in the user's timezone (ISO 8601 with offset) - All active facts about the user (preferences, personal info, relationships) - tasks_overdue: Tasks with scheduled_date OR deadline in the past - tasks_today: Tasks scheduled OR due today (time >= now), plus unscheduled tasks (no date set) - tasks_tomorrow: Tasks scheduled OR due tomorrow (includes projected recurring tasks) - Active goals - Recent moments from the last 5 days - Latest 15 user-facing notes (id + description). Use get_note to retrieve full content. - ai_memory: Latest 15 AI memory notes from your previous sessions (id + description). Use get_note to retrieve full content. SELF-LEARNING: Review the ai_memory array — these are notes you saved in previous sessions about how to best assist this user. Load relevant ones with get_note. Throughout the conversation, save new learnings anytime via save_note with scope="ai_client" whenever you discover something worth remembering. - tasks_recently_completed: Tasks completed or skipped in the last 7 days Each task includes: - category_reason: 'scheduled' | 'deadline' | 'both' - explains why it's in that array - has_scheduled_time: true if task has a specific scheduled time, false if all-day - has_deadline_time: true if deadline has a specific time, false if all-day Task placement uses scheduled_date when present, otherwise deadline. Each task appears in exactly one category. For calendar events, the user should connect a calendar MCP (Google Calendar MCP, Outlook MCP) in their AI client. Query those MCPs alongside Anamnese for a complete daily view. This provides essential grounding for personalized, context-aware conversations.
    Connector
  • Returns one row per civil day for a calendar month at a location with condensed tithi, vara, nakshatra, yoga, karana, and rahu_kaal columns. SECTION: WHAT THIS TOOL COVERS Month-wide Panchanga suitable for planners; each day includes ending times where applicable and local Rahu Kaal bounds. Year must be 1900–2100 and month 1–12 (Pydantic on PanchangaCalendarInput). It is not single-day detailed Panchanga (asterwise_get_panchanga) nor muhurta search (asterwise_get_muhurta). SECTION: WORKFLOW BEFORE: None — this tool is standalone. AFTER: asterwise_get_panchanga — expand any single day at full detail. SECTION: INPUT CONTRACT year/month/lat/lon validated locally. Timezone handling follows upstream response fields (data.timezone echo). SECTION: OUTPUT CONTRACT data.year (int) data.month (int) data.timezone (string) data.ayanamsa (string) data.days[] — 28–31 objects: date (string — YYYY-MM-DD) tithi — { name (string), number (int), paksha (string), end_time (string — ISO UTC) } vara — { name (string), number (int), lord (string) } nakshatra — { name (string), index (int), pada (int), end_time (string — ISO UTC) } yoga — { name (string), index (int), is_inauspicious (bool), end_time (string — ISO UTC) } karana — { name (string), number (int), end_time (string — ISO UTC) } rahu_kaal — { start (string — HH:MM local), end (string — HH:MM local) } SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS FAST_LOOKUP SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): — year outside 1900–2100 → MCP INVALID_PARAMS — month outside 1–12 → MCP INVALID_PARAMS — lat/lon out of range → MCP INVALID_PARAMS INVALID_PARAMS (upstream): — None — further rejection surfaces as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Day count follows the civil month (28–31 entries). SECTION: DO NOT CONFUSE WITH asterwise_get_panchanga — deep single-day Panchanga with degree fields, not a month grid. asterwise_get_muhurta — activity-ranked windows, not a passive calendar.
    Connector
  • Update an existing calendar event. Use fetch_calendar_events first to get the event_token. Supports partial updates - only provide fields you want to change. Note: Cannot update events to past dates. # update_calendar_event ## When to use Update an existing calendar event. Use fetch_calendar_events first to get the event_token. Supports partial updates - only provide fields you want to change. Note: Cannot update events to past dates. ## Parameters to validate before calling - event_token (string, required) — The event token to update (UUID format, required) - title (string, optional) — New event title (optional) - start_date (string, optional) — New start date in ISO 8601 format (optional) - end_date (string, optional) — New end date in ISO 8601 format (optional) - description (string, optional) — New event description (optional) - location (string, optional) — New event location (optional) - start_time (string, optional) — New start time in HH:MM format (optional) - end_time (string, optional) — New end time in HH:MM format (optional) - color (string, optional) — New event color in hex format (optional) - all_day (boolean, optional) — Whether this is an all-day event (optional) - status (string, optional) — New event status (optional) - private_event (boolean, optional) — Whether this is a private event (optional) - sms_notification (boolean, optional) — Enable SMS notifications (optional) - completed (boolean, optional) — Mark event as completed (optional) - latitude (number, optional) — New location latitude coordinate (optional) - longitude (number, optional) — New location longitude coordinate (optional) - event_url (string, optional) — New URL associated with the event (optional) - people_involved (string, optional) — New people involved in the event (optional) - repeat_this_event (string, optional) — New repeat configuration (optional) - notification (string, optional) — New notification settings (optional) ## Notes - Cannot move events to past dates (UTC). Use tomorrow or later
    Connector