"How to Use Google Calendar" matching MCP tools:

• intentions_ask_month

  Intentions MCP Server

  Call when the user asks at month granularity or wants the best month from a multi-month window ("how is next month", "best month in 2026 to X", "下个月适合吗"). Use for trip-month selection, launch months, content-calendar planning, quarterly/annual decisions. Modes: single month, compare up to 5 months, or scan up to 12 months (returns top 5). Returns month score, element breakdown, adverse alerts. For day precision near the 4th–6th of a month use `intentions_ask_day`; for hour precision use `intentions_ask_hour`.

  Connector

• delete_events

  reassign

  Delete events or clear whole days — bulk/batch, one or many in a single call. Pass `ops`, an array where each item has an `op` (delete | clear): `delete` removes one event by id (for a recurring event set `scope` 'all' (default) / 'future' / 'this' with `occurrenceDate`); `clear` removes everything on a day (or a `date`..`to` range). By default the whole batch is atomic: if ANY op fails, nothing is removed; pass `partial: true` for best-effort. Every removal is reversible — the response returns an `undoToken` (call undo within 30 minutes). If the user has a Google Calendar connected, deleting a calendar-linked event also removes it from Google — the same as deleting on the dial; an event get_schedule/find_event marks `readOnly` is from a calendar the user doesn't own and can't be deleted this way. It reports `applied`, `failed`, `skipped`, and per-op `results` (each with its 0-based `index`). To create or edit events use write_events.

  Connector

• get_public_deadlines

  mcp

  Compute the universal Norwegian regulatory filing calendar — the set of deadlines that apply to every Norwegian business of the covered categories (MVA, A-melding, Årsregnskap), independent of any specific organisation. The response is the calendar for a single Europe/Oslo calendar year, one entry per (obligation, period) pair with: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`, `A_MELDING_MONTHLY`, `ARSREGNSKAP_FILING`); the due_date as an ISO 8601 timestamp in Europe/Oslo (DST-aware — CET ↔ CEST transitions never shift due dates by a calendar day); the legal_reference citation pinning the deadline to lovdata.no; a recurring boolean; and a business_day_adjusted boolean. Choose this tool when an agent needs the universal calendar (questions like 'when is the next MVA filing deadline' that don't depend on a specific org_number) — it requires no organisasjonsnummer and no scope check beyond rulebook read access. Input: optional `year` (Europe/Oslo calendar year, integer between 2020 and 2100; defaults to the current Oslo year at the endpoint when omitted — a request at 23:30 UTC on 31 Dec is already 00:30 of the next year in Oslo during CET, and the route's default uses the Oslo wall-clock not UTC). Determinism (Rule 9): same input + same rulebook_version produces a byte-identical calendar. Failure modes: SCOPE_INSUFFICIENT if the API key is not scoped read:rulebook; VALIDATION_FAILED on year shape (non-integer, outside 2020–2100; the 2020 lower bound matches the underlying /v1/public/deadlines route's MIN_YEAR — older years aren't in the Rulebook's coverage window). Required scope: `read:rulebook`. For a specific company's filing calendar rather than the universal one, use get_company_deadlines instead.

  Connector

• generate_calendar_events

  Celestine

  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

• schedule

  reassign

  Find conflict-free time and place one or more events — the easiest way to book work without computing slots yourself. YOU resolve any relative phrasing ("tomorrow", "next monday", "this afternoon") into the structured fields; this tool does no date parsing. Pass `requests`, each with a `name`, `duration` ("90m", "1h30", "2h"), a `date` (ISO "YYYY-MM-DD"), and EITHER an exact `start` ("HH:MM", 24-hour) to place there, OR an `earliest`/`latest` ("HH:MM") window to search within (map "afternoon" → earliest "13:00", latest "18:00"), OR neither to search the whole working day. For each request: if exactly one conflict-free time fits it is created immediately with an `undoToken`; otherwise you get ranked `options` and a `commitToken` — call confirm_schedule to pick one. Requests are placed in order and kept off each other's committed slots. Each request may carry a `request_id` so retries don't double-book. If the user has a Google Calendar connected with a default sync calendar, a scheduled event is also pushed to Google, the same as a dial create. The response reports per-request `results` (each with its 0-based `index`).

  Connector

• lyra_get_shared_availability

  lyra-mcp-server

  Returns busy windows for YOU plus a set of named attendees from your Lyra contacts, within a time window. For each attendee you provide, the tool looks up whether their Lyra profile has a connected Google calendar; if so, their busy blocks contribute to the aggregated suggested_free_intervals. If not (or if they're not a linked Lyra profile), they're marked requires_manual_confirm: true so you know to ask them directly. Cap of 8 attendees per call. Privacy: per-attendee busy time ranges are returned, never event titles or summaries. Use this when you need to find a time that works for several people at once. Requires an active Google calendar connection on your own Lyra account and API key authentication.

  Connector

• google_ads_list_accessible_customers

  paid-ads

  Lists directly accessible Google Ads customers for the configured Google Ads credentials, including descriptive names when Google returns them. Use this to discover customer IDs before running Google Ads hierarchy or reporting tools.

  Connector

• lyra_connect_calendar

  lyra-mcp-server

  Returns a URL the user should open in their browser to connect a calendar. Google Calendar is supported today; Microsoft and Apple are planned. The user must be signed in to checklyra.com first. Once they grant consent, Lyra stores an encrypted refresh token and the connection becomes available to other Convene tools. Requires API key authentication for the calling agent (so we know which user is asking).

  Connector

• gcal_list_calendars

  Google_calendar

  List all accessible calendars. Returns calendar IDs, names, time zones, and your access level for each. Use to identify which calendar to query or modify.

  Connector

• get_snds_status

  email-deliverability

  Report whether Microsoft SNDS is connected for the org, the last sync time + status, how many sending IPs are tracked, and how many are currently blocked by Outlook/Hotmail. Use before get_snds_ip_stats to confirm the integration is live.

  Connector

• request_device_auth

  mkdshare.DEV

  Start a headless Google sign-in. Call this FIRST if you don't have an API token yet. Returns a user_code and verification_url for the user to visit, plus a device_code to use with poll_device_auth. No Bearer token required.

  Connector

• maps_place_details

  Google_maps

  "Hours / phone / reviews of [business]" / "Google business info for [place]" / "is [restaurant] open" — full details for a Google Place: address, phone, hours, website, ratings, user reviews. Requires a place ID from `maps_place_search`. Use after search to drill into one specific business.

  Connector

• maps_directions

  Google_maps

  "Google Maps directions from A to B" / "transit / public-transport directions" / "bus / subway / train route" / "best way to get from [X] to [Y]" — turn-by-turn directions via Google Maps. Modes: driving, walking, transit (bus/subway/train), bicycling. Requires Google Maps API key. PREFER over Mapbox/OpenRouteService specifically for public-transit routing — Google has the best transit data.

  Connector

• maps_distance_matrix

  Google_maps

  "Travel time matrix between [N] origins and [M] destinations" / "drive-time grid via Google Maps" / "transit times between addresses" — N×M distance and duration matrix between many points via Google Maps. Modes: driving, walking, bicycling, transit. Use for delivery routing, multi-stop optimization, transit-heavy planning.

  Connector

• intentions_ask_year

  Intentions MCP Server

  Call when the user asks about a full calendar year as a whole ("how is 2026", "今年怎么样", "what's next year like overall"). Returns year-level score, verdict, adverse alerts, and element dimensions. For month precision use `intentions_ask_month`; for day use `intentions_ask_day`. Window: currentYear-1 to currentYear+1 only.

  Connector

• google_scholar

  Searchapi

  Search Google Scholar for academic papers, citations, and scholarly articles. Returns results with titles, authors, publication info, citation counts, and links to PDFs. Use cites parameter to find papers citing a specific work, or cluster to find all versions of a paper. For US court opinions and case law, use google_scholar_cases instead.

  Connector

• resolve_maps_urls

  Google Maps

  Resolves a list of Google Maps URLs into canonical Google Maps Place IDs. **When to call this tool (CRITICAL):** * Use this tool when the user provides one or more Google Maps sharing links or URLs (e.g. 'https://maps.app.goo.gl/...', 'https://www.google.com/maps/place/...', or 'https://maps.google.com/...') and you need to extract the underlying canonical Place IDs. * You can specify up to 20 URLs to resolve in a single batch request. **Input Requirements (CRITICAL):** * **`urls` (array of strings - MANDATORY):** The list of Google Maps URLs to resolve. Each URL must be a valid, single-place Google Maps URL. **Error Handling (CRITICAL):** * This is a batch processing tool. A request might return "mixed results" (e.g. some URLs resolve successfully while others fail). * The output list of `entities` is guaranteed to map 1:1 with the input `urls` indices. A failed URL resolution will result in an empty `Entity` message (no fields are set) at its corresponding index in the `entities` list. * You **MUST** check the `failed_requests` map field in the response to identify which specific URL index failed. The key of `failed_requests` represents the 0-based index of the failed URL in the request. Do not assume the entire batch call failed because of a partial failure.

  Connector

• get_user_profile

  anamnese

  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

• write_events

  reassign

  Create, update (edit), move/reschedule, or shift events — bulk/batch, one or many in a single call. Pass `ops`, an array where each item has an `op` (create | update | move | shift) plus that op's fields; a single edit is just a 1-item array. Times are 24-hour HH:MM; for an event crossing midnight set endNextDay=true. For a recurring event choose a `scope`: 'all' (default), 'future', or 'this' (the last two need `occurrenceDate`). move changes start/date keeping duration; shift nudges by `byMinutes`. By default the whole batch is atomic: if ANY op fails validation (e.g. a conflict), nothing is written and the failing ops are returned as errors — fix and resend. Pass `partial: true` for best-effort (apply what's valid). Ops apply in order as one transaction and are checked against each other: two creates can't double-book a slot, and an earlier move frees a slot a later op can reuse. Target each event id at most once per batch. Reference an area/activity type by id or by `areaName`/`activityTypeName`; create new ones first with manage_categories. If the user has a Google Calendar connected, creating or editing a calendar-linked event (or one created under their default sync calendar) also pushes the change to Google — the same as editing on the dial; don't edit an event get_schedule/find_event marked `readOnly` (it's from a calendar the user doesn't own and the change would silently revert). To remove events or clear a day use delete_events. The response reports `applied`, `failed`, `skipped` (validated but not written because the atomic batch was rejected), and per-op `results` (each with its 0-based `index`).

  Connector

• get_schedule

  reassign

  Read the calendar — the day's agenda, what's on, how busy you are, your availability, an overview of your day or week, where your time is going. Returns everything needed to reason about the plan in one call: the current time (`now`), the user's `areas` and `activityTypes`, `userPreferences`, and a `days` array (one entry per requested day) with that day's events, free slots within the day, and how its time splits across areas and activity types (`loadByArea`/`loadByActivityType` count blocking time only; any non-blocking overlay minutes — sleep, fasting — are reported separately as `nonBlockingLoadByArea`/`nonBlockingLoadByActivityType` when present). Call it before scheduling to anchor relative times. Defaults to today; pass `date` for another single day, `from`+`to` for an inclusive range, or `dates` for a specific set (ISO YYYY-MM-DD, e.g. "2026-06-01"). Pass `compact: true` to shrink each day's events (no decimal hours/label; area and activity type as ids referencing the top-level `areas`/`activityTypes`) — prefer it for wide ranges. Pass `includeSeries: true` to also get recurring masters (rule, anchor, next occurrence) as `series`. Each event carries its `source` ("reassign" for a native event, else the provider like "google") and, when calendar-linked, its `calendar` name; an event with `readOnly: true` is from a calendar the user doesn't own — don't edit or delete it. An event's `kind` is omitted when it's a normal "blocking" event; `kind: "non-blocking"` is an overlay (sleep, fasting) that may overlap others; `kind: "reference"` is see-only — something the user wants to view but isn't working on (its hours stay free for scheduling; don't move, delete, or schedule work into it unless asked). When the user has connected a calendar, `integrations` describes the setup: a `sources` array (one per connected provider) each with its `calendars`, the account-wide AI classifier (`aiClassify`/`aiContext`) and the `defaultSyncCalendarId` new events sync to. Per calendar it carries the fallbacks that decide how synced events are classified when the AI is unsure — `defaultKind` (block type), `defaultArea`/`defaultType` (referencing the top-level taxonomy), and the free-text `instructions` hint — plus `writable`. Use it to explain why an event came in non-blocking, or where a new event will sync. It's omitted when no calendar is connected. Times are in the user's `timezone`; events with no title show as "(untitled)".

  Connector