Skip to main content
Glama

Read events

events_list
Read-only

Read what is on - the meetings, appointments and other events of a period, an agenda or schedule - across every connected calendar, earliest first, or latest first with newestFirst. query finds the events whose title, description, place, organizer or guests hold every word it names - a person by name or address included - on every account: Google searches its own, while Outlook, which searches titles alone, is read across the period and matched here. account, with provider where two share an address, reads that account alone, and calendarId, as calendars_list names it, that one of its calendars alone. Each event answers once, naming under copies every account and calendar holding it, with that copy's id, how it shows there and that account's own answer. An occurrence of a recurring series names under originalStart the start its series gave it, which a moved one keeps, and under each copy that account's seriesId. A calendar shared into one account from another connected account is read through its owner alone. Lumman's own busy copies - private blocks titled "Busy · (Multi Calendar connector)", on iCloud, which keeps no private events, or a calendar server, which may keep none, blocks titled "Busy (Multi Calendar connector)" - are never among the events: busyCopies answers them apart, one entry per copied busy time with its start and end, the account it copies under copyOf - unknown where no record of it stands - and each account it stands in under standsIn. None counts as the person's time or can be moved or cancelled; each is a busy copy of the account under copyOf, switched off at https://lumman.co/mcp/account/multi-calendar or by taking that pair away with busy_everywhere_set. Every time is given with its offset in the zone the answer names under timeZone: the one passed, else the person's stored zone, which now names with their time now; an all-day event's start and end are dates, its end the day after its last. An answer, a guest's or an account's own, is accepted, tentative, declined, unanswered or organizer, and one a copy cannot know is left out. An event names its kind where it is no ordinary event - a Google outOfOffice, focusTime, workingLocation, birthday or fromGmail entry - its privacy where it is not normal: public, private, confidential or personal - and its Teams, Zoom or Meet join link, and each copy its webLink; an out-of-office event shows as away. A description is its first 255 characters, marked descriptionCut where it goes on: events_get reads it. Where more events are read than one answer carries, the last in its order are left out and counted under leftOut with the period holding them all, which a narrower period or one calendar at a time reads further. A meeting whose guests alone one answer cannot carry names the first that fit, omittedAttendees counting the rest. Each calendar answers at most 50 events, read in time order; one with more is named under cutShort with its calendarId, readTo - the start of the last event read - and continueAt: passed with its account and calendarId, the same period and query, it reads on from exactly where it stopped; latest first, such a calendar's latest events are the ones past readTo, reached only by reading it on. A calendar or an account that could not be read, or that the person does not let you see, is named under unread with why: needs_reconnection, not_allowed, refused, gone, rate_limited or unavailable; where nothing could be read the answer is an error. An account named under unread as needs_reconnection carries its own row under reconnectAt, where the person, signed in as the same account, presses "Reconnect"; calls to it answer again only once they have. malformed counts events a provider sent in a form that could not be read, each left out. An event whose words screen as a prompt attack is left out and named under withheld by its start, its end and each copy's account, calendarId and id - by account alone where an id screened so - and a calendar whose name screened so is named by its account alone.

Input Schema

NameRequiredDescriptionDefault
toYesEnd of the period, excluded, in the same forms.
fromYesStart of the period, included: e.g. 2026-10-12, 2026-10-12T09:00 or 2026-10-12T09:00:00+01:00.
queryNoWords, or a person by name or address, every one of which an event must hold.
accountNoThis connected account alone is read, by the address calendars_list names.
providerNoThe account's provider, as calendars_list names it; needed only where two connected accounts share an address.
timeZoneNoAn IANA zone such as Europe/London to answer in; the person's stored one where omitted.
calendarIdNoThis calendar of the account named alone is read, by the calendarId calendars_list names.
continueAtNoA cutShort entry's continueAt, with its account and calendarId: the read goes on from where that calendar was cut.
newestFirstNotrue answers the latest events first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / account / description
      Previous value: -"Read this connected account alone, by the address calendars_list names."New value: +"This connected account alone is read, by the address calendars_list names."
    • changedInput schema / properties / calendarId / description
      Previous value: -"Read this calendar of the account named alone, by the calendarId calendars_list names."New value: +"This calendar of the account named alone is read, by the calendarId calendars_list names."
    • changedInput schema / properties / continueAt / description
      Previous value: -"Read on from where a calendar under cutShort was cut: its continueAt, with its account and calendarId."New value: +"A cutShort entry's continueAt, with its account and calendarId: the read goes on from where that calendar was cut."
    • changedInput schema / properties / newestFirst / description
      Previous value: -"Answer the latest events first."New value: +"true answers the latest events first."
  2. Changed1 schema field changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
      -  "google",
      -  "microsoft",
      -  "icloud"
      -]New value: +[
      +  "google",
      +  "microsoft",
      +  "icloud",
      +  "caldav"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
      -  "google",
      -  "microsoft"
      -]New value: +[
      +  "google",
      +  "microsoft",
      +  "icloud"
      +]
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly/non-destructive/openWorld=false; the description goes far beyond by disclosing the 50-event-per-calendar cap, cutShort/readTo/continueAt pagination, leftOut and omittedAttendees truncation, unread reasons (needs_reconnection, rate_limited, etc.), withheld prompt-attack filtering, malformed counts, and how Lumman's busy copies are separated into busyCopies. This is unusually rich behavioral disclosure for a read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, and most sentences carry non-redundant information, but the entire body is one dense paragraph with no structure, mixing return-value details, pagination rules, busy-copy explanation, and error semantics. It is readable only with effort and could be segmented or trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must carry the entire return contract — and it does: event fields, per-copy metadata, timeZone/offset handling, all-day date semantics, response statuses, privacy/kind fields, join links, and every truncation/error bucket. An agent has what it needs to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description still adds meaningful semantics, notably that query matches every word across title/description/place/organizer/guests, that Outlook is searched by title alone while Google searches its own index, and the exact continuation protocol for continueAt with account+calendarId. These go beyond the schema's per-parameter blurbs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource — reading meetings, appointments and other events of a period across every connected calendar — and distinguishes the result ordering (earliest first, or newestFirst). An agent can immediately tell this is a multi-calendar event listing, distinct from events_get, events_create or free_times_find.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to narrow with query, account, provider, calendarId, or continueAt, and points to events_get when the full description is needed. It stops short of an explicit when-not-to-use or a named alternative for other listing needs (e.g. calendars_list), but the routing context is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.