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 — fasting, an away marker — 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 (e.g. fasting, an away marker) 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). A past day the user confirmed ("this is how it went") carries a `review` block: `reviewed: true`, `reviewedAt`, and an `adherence` rollup read from the frozen reflection snapshot — `event` and `layer` scores (0–1, how closely the day matched the plan), `plannedHours`/`unplannedHours`, and per-area/per-activity-type breakdowns (`byArea`/`byActivityType`, keyed by id). Use it to answer how a day or week actually went; an unreviewed day has no `review` block. Per-event actuals ride each event's `reflect` block. 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`, and `aiRules` — the user's scattered guidance compiled into one conflict-free ruleset the classifier follows) 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) and `defaultArea`/`defaultType` (referencing the top-level taxonomy) — 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. When a single day (or today) is requested and the user has a city, a one-line `weather` headline for that day is included (temp range, condition, rain window, sunset) — enough to schedule around; call get_weather only when an outdoor plan needs the hourly detail. Times are in the user's `timezone`; events with no title show as "(untitled)".