list_calendarsList calendars owned by the authenticated user. Returns id, name, description, image id, and whether the calendar is shared. Does not include calendars of other users.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| calendars | Yes | Calendars owned by the authenticated user |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the ownership scope and the list of returned fields, which is useful. However, it doesn't mention pagination, ordering, or whether deleted calendars are included, though these are not critical for a simple list tool with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The purpose is stated first, followed by return fields and an exclusion note. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema in the prompt (though context says it exists), and annotations cover safety, the description is nearly complete. It names return fields and scope. Minor gaps like pagination or sorting exist, but for a simple list operation, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). The description compensates beautifully by listing the exact fields returned (id, name, description, image id, shared status), giving the agent full clarity on output semantics. Since there are no params, the baseline is 4, and the description exceeds it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists calendars owned by the authenticated usercars, enumerates the returned fields (id, name, description, image id, shared status), and explicitly excludes other users' calendars. This is specific and distinguishes it from any tool that might list all calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies an ownership scope ('owned by the authenticated user') and states what it does not include ('does not include calendars of other users'). While it doesn't name alternative tools or conditions, given the sibling list includes many event-related tools, this tool is clearly for calendar listing and the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.