list_calendar_eventsRetrieve upcoming events from connected Google Calendars to see scheduled meetings and plan bot participation.
Upcoming events from connected Google Calendars (connect via POST /calendar/create_calendar with google_client_id/secret/refresh_token — needs OAuth credentials, usually done once from the dashboard or CLI).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description need not repeat that. It adds value by noting OAuth credentials are needed and that the connection is usually done once, but it doesn't disclose potential rate limits, data freshness, or what happens if no calendars are connected. No contradiction with annotations.
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?
The description is a single parenthetical sentence that is concise and readable. It front-loads the core action 'Upcoming events' and then the setup detail, which is efficient. No filler words.
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 zero parameters, no output schema, and a readOnlyHint annotation, the description is fairly complete. It explains the source and the pre-requisite setup, which is important. However, it lacks clarity on the date range of 'upcoming' and what the returned events include, which an agent might need to decide if this is the right tool.
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?
There are zero parameters, and the schema has no properties. The description clarifies the source (connected Google Calendars), which is essential context. Since there are no parameters to document, a baseline of 4 is appropriate.
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 states it lists upcoming events, but it's vague about what 'upcoming' means and doesn't distinguish it from the many sibling tools. The verb and resource are clear, but the scope is ambiguous and does not differentiate from scheduling tools.
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?
It mentions a prerequisite for connecting Google Calendars, which is useful but not directly a usage guideline for when to call this tool. There is no guidance on when to use this vs. alternatives, and the connection detail is more about setup than invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.