Skip to main content
Glama
JoeCardoso13

Google Calendar MCP Server

by JoeCardoso13

List Events

list_events

Retrieve events from a Google Calendar within a given time range, with optional sorting, pagination, calendar ID, and result limits.

Instructions

List events from a calendar within a time range.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
order_byNoSort order: 'startTime' (default) or 'updated'startTime
time_maxNoEnd of time range (RFC3339)
time_minNoStart of time range (RFC3339, e.g. '2026-03-01T00:00:00Z')
page_tokenNoToken for next page of results
calendar_idNoCalendar ID (default: 'primary')primary
max_resultsNoMaximum number of events to return

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It conveys only that results are scoped to a time range; it does not mention that results are paginated (a page_token parameter exists), what the default sort is, or that the default target is the 'primary' calendar when no calendar_id is given.

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

Conciseness4/5

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

One short sentence with the verb and scope front-loaded and no wasted words. It is efficient, though arguably too terse to earn a top score given the tool's six parameters.

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

Completeness3/5

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

Because an output schema exists, return values need not be explained, and the schema documents every parameter. The remaining gap is the absence of any routing guidance against search_events and no note on pagination or default calendar selection.

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 all six parameters are documented in the schema itself (including RFC3339 format, defaults, and sort options). The description adds only a generic time-range notion, matching the baseline for high schema coverage.

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

Purpose4/5

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

The description states a specific verb (List) and resource (events) plus the scoping dimension (within a time range). It clearly separates from list_calendars and get_event, but gives no signal to distinguish it from the sibling search_events, which is the closest alternative.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no named alternative. An agent cannot tell from this text whether to call list_events or search_events for a filtered query, nor whether a calendar_id or time range is required in practice.

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