Skip to main content
Glama
Sign In
Chronary

Chronary

Official
by Chronary
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_events

Read-onlyIdempotent

Retrieve events from a calendar or all of an agent's calendars, including internal and synced iCal events. Filter by time window, status, or source to find specific events.

Instructions

List events on a calendar or across an agent's calendars, including internally created events and externally synced events from iCal subscriptions (e.g. Google Calendar, Outlook). Provide calendar_id OR agent_id. Narrow with start_after/start_before (time window), status, and source.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results to return
expandNoExpand recurring series into individual occurrence instances within the window. Requires both start_after and start_before (max 366 days apart). Instances carry recurringEventId + originalStartTime.
offsetNoPagination offset
sourceNoFilter by source: "internal" (created via the API) or "external_ical" (synced from an iCal subscription)
statusNoFilter by event status
agent_idNoAgent ID to list events for across all of the agent's calendars. Provide this or calendar_id.
calendar_idNoCalendar ID to list events from. Provide this or agent_id.
start_afterNoOnly events starting after this ISO 8601 time
start_beforeNoOnly events starting before this ISO 8601 time

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.3
    • changedInput schema / properties / start_after / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
    • changedInput schema / properties / start_before / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  2. Changed1 schema field changedv1.4.1
    • addedInput schema / properties / expand
      Added value: +{
+  "default": false,
+  "description": "Expand recurring series into individual occurrence instances within the window. Requires both start_after and start_before (max 366 days apart). Instances carry recurringEventId + originalStartTime.",
+  "type": "boolean"
+}
  3. First observedv1.2.5

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful substance by disclosing that results span internal and externally synced events, but says nothing about pagination behavior, ordering, or result limits beyond what the schema states, leaving it at a modest add.

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

Conciseness5/5

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

Three tight sentences: purpose and scope first, then the required identifier constraint, then the optional filters. No filler and no redundancy with the schema; each clause carries distinct information.

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

Completeness4/5

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

For a read-only list tool with 100% schema coverage and no required parameters, the description covers what the tool returns conceptually and how to scope the query. The only shortfall is that with no output schema present, it could have said more about the returned event shape or pagination envelope, though for a list operation this is a minor gap.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 9 parameters is already documented, including the mutual-exclusivity note on calendar_id/agent_id and the enum values for source and status. The description reinforces which parameters matter but adds no syntax, format, or constraint detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb (List) and resource (events), and goes further by scoping it to a calendar or across an agent's calendars while explicitly including both internally created and externally synced iCal events. This lets an agent distinguish it from single-event siblings like get_event and from list_calendars without opening any schema.

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?

Gives a clear usage rule: 'Provide calendar_id OR agent_id', and enumerates the narrowing filters (start_after/start_before, status, source). It supplies positive context but never names an alternative tool or a when-not-to-use condition (e.g. get_event for a single event), so it stops short of full routing guidance.

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

Deploy Server

Other Tools