Skip to main content
Glama

calendar_list_calendars

Read-only

List all event calendars with their names and IDs to find the exact calendar values other calendar tools require. Use when a calendar name is unknown or a tool reports no matching calendar.

Instructions

List the owner's event calendars by name and id, so you know the exact values the other calendar tools accept.

Use when: a calendar name is unknown, a tool reported "No calendar named ...", or before creating an event in, moving to or deleting a specific calendar. Not for events (use calendar_list_events), for Reminders lists (use reminders_list_lists), or for testing the CalDAV connection (use icloud_check_health). Parameters: none; it always covers every calendar on the account that can hold events. Behavior:

  • Read-only; changes nothing.

  • Calendars that cannot hold events (Reminders lists) are left out.

  • The list is cached for up to 2 minutes, so a calendar just added in the Calendar app can appear a little later; calendars created, renamed or deleted through these tools show at once. Returns: a list of {name, id}. Other calendar tools accept either value and match names in any case. An empty list means the account has no event calendars. Errors: a sign-in or connection failure raises an error saying so; run icloud_check_health.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "items": {
      -        "additionalProperties": true,
      -        "type": "object"
      -      },
      -      "title": "Result",
      -      "type": "array"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "calendar_list_calendarsOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed1 schema field changedv0.7.0
    • removedInput schema / title
      Removed value: -"calendar_list_calendarsArguments"
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the 2-minute cache and its staleness rules, the exclusion of Reminders lists, the exact return shape, and the error/sign-in failure path. This is the kind of context annotations cannot carry.

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?

Front-loaded with purpose, then cleanly sectioned into Use when / Parameters / Behavior / Returns / Errors. Every line carries information, though the total length is slightly heavy for a zero-argument list tool and a couple of clauses restate what the Returns section already implies.

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?

For a no-parameter, read-only listing tool with no output schema, the description covers everything an agent needs: when to call it, what it excludes, caching caveats, return format, and failure handling. No meaningful gap remains.

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?

Zero parameters, so the baseline of 4 applies. The description usefully adds that there are no parameters and that the list always covers every event-capable calendar, plus that other tools accept either name or id case-insensitively, which is helpful even though no schema fields exist to document.

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 and resource ('List the owner's event calendars') and immediately scopes it to the values other calendar tools accept. It explicitly distinguishes itself from calendar_list_events, reminders_list_lists, and icloud_check_health by name, so an agent can route 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 Guidelines5/5

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

Provides an explicit 'Use when' clause with three concrete triggers (unknown name, 'No calendar named...' error, before create/move/delete) and an explicit 'Not for' clause naming the correct alternatives for each adjacent need. Nothing is left to inference.

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