mcp-google-workspace

Overview Schema Source Related Servers Discussions Admin

Calendar Get Calendar Digest

calendar_get_calendar_digest

Read-onlyIdempotent

Summarize upcoming primary calendar events from now through a chosen number of days, including recurring items and pending invitations, so users can see their schedule and what needs a response.

Instructions

Summarize the user's upcoming schedule: events on the primary calendar from now until the given number of days ahead, with recurring events expanded. Use it for "what is on my calendar" and pending invitations; for another calendar or a specific window use calendar_search_events. Returns events (compact, earliest first), count, account_timezone, and requires_response: the events whose invitation the user has not answered yet, which calendar_respond_to_event can answer.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calendar_get_calendar_digest"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Length of the window in days, starting now.
`max_results`	No	Maximum events to return, earliest first; events past this count are left out.

Output Schema

Name	Required	Description
`count`	No	Number of items in this response.
`events`	No
`has_more`	No	Whether another page is available.
`fetched_at`	No	RFC3339 time when this response was fetched.
`next_page_token`	No	Opaque token for the next page, or null.
`account_timezone`	No
`window_day_count`	No
`requires_response`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.1.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower; the description still adds real behavior beyond them by stating recurring events are expanded, results are compact and earliest-first, and by explaining what the requires_response field means. It stops short of describing truncation behavior when max_results is hit or any cost/latency characteristics, which keeps it at 4 rather than 5.

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?

Purpose and scope are front-loaded in the first clause, followed by usage routing and return semantics in a logical order with no filler sentences. The second sentence is clause-dense (return fields, ordering, requires_response, follow-up tool) and could be split for faster scanning, which is the only deduction.

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 two-optional-parameter read tool with an output schema and full annotation coverage, the description is close to complete: purpose, alternatives, ordering, and the meaning of the non-obvious return field are all present. Only the behavior at the max_results boundary is left implicit.

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 coverage is 100%, so both parameters are already documented as window length and earliest-first cap. The description restates the window and ordering semantics without adding syntax or edge-case guidance, so the baseline 3 for schema-covered parameters is the right score.

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?

The description opens with a specific verb plus resource ('Summarize the user's upcoming schedule') and pins the scope precisely: primary calendar only, from now to N days ahead, recurring events expanded. It explicitly names the neighboring capability it is not ('for another calendar or a specific window use calendar_search_events'), so an agent can choose between them without opening either 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?

It gives both an affirmative use case ('what is on my calendar' and pending invitations) and the exclusion condition plus the named alternative (calendar_search_events for a non-primary calendar or a specific window). It also routes the follow-up action by naming calendar_respond_to_event for the unanswered invitations it returns.

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

Deploy Server