Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Get Events

get_events

Read-onlyIdempotent

Fetch Google Calendar events by event ID, time range, or keyword. Returns detailed event info like attendees, locations, and attachments when needed.

Instructions

Retrieves events from a specified Google Calendar. Can retrieve a single event by ID or multiple events within a time range. You can also search for events by keyword by supplying the optional "query" param.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	No	A keyword to search for within event fields (summary, description, location). Ignored if event_id is provided.
`detailed`	No	Whether to return detailed event information including description, location, colour (colorId), attendees, and attendee details (response status, organizer, optional flags). Recurring instances also report the parent series ID needed to edit the whole series; recurring masters report their raw RFC5545 recurrence rules; and events that are not ordinary confirmed meetings report their event type (outOfOffice, workingLocation, focusTime) and status. Defaults to False.
`event_id`	No	The ID of a specific event to retrieve. If provided, retrieves only this event and ignores time filtering parameters.
`time_max`	No	The end of the time range (exclusive) in RFC3339 format. If omitted, events starting from `time_min` onwards are considered (up to `max_results`). Ignored if event_id is provided.
`time_min`	No	The start of the time range (inclusive) in RFC3339 format (e.g., '2024-05-12T10:00:00Z' or '2024-05-12'). If omitted, defaults to the current time when single_events=True. It is omitted from unexpanded queries so recurring masters that began in the past but still have future occurrences remain discoverable. Ignored if event_id is provided.
`page_token`	No	Token for the next page, taken from a previous response. When single_events=True, also pass the response's Pagination time_min as time_min, even if omitted on the first call. Keep all other query parameters unchanged. Ignored if event_id is provided.
`calendar_id`	No	The ID of the calendar to query. Use 'primary' for the user's primary calendar. Defaults to 'primary'. Calendar IDs can be obtained using `list_calendars`.	primary
`max_results`	No	The maximum number of events to return in one page. Defaults to 25. Ignored if event_id is provided.
`single_events`	No	Whether to expand recurring series into individual instances. Defaults to True for backwards compatibility. Set to False with detailed=True to retrieve recurring master events and their exact RFC5545 recurrence rules instead of inferring cadence from expanded instances.
`user_google_email`	Yes	The user's Google email address. Required.
`include_attachments`	No	Whether to include attachment information in detailed event output. When True, shows attachment details (fileId, fileUrl, mimeType, title) for events that have attachments. Only applies when detailed=True. Set this to True when you need to view or access files that have been attached to calendar events, such as meeting documents, presentations, or other shared files. Defaults to False.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.28.0Sep 24, 2026

removedInput schema / properties / event_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / event_id / type
```
Added value: +"string"
```

removedInput schema / properties / page_token / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / page_token / type
```
Added value: +"string"
```

removedInput schema / properties / query / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / query / type
```
Added value: +"string"
```

removedInput schema / properties / time_max / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / time_max / type
```
Added value: +"string"
```

removedInput schema / properties / time_min / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / time_min / type
```
Added value: +"string"
```

Changed2 schema fields changedv1.26.0Sep 6, 2026

changedInput schema / properties / max_results / description

Previous value: -"The maximum number of events to return. Defaults to 25. Ignored if event_id is provided."New value: +"The maximum number of events to return in one page. Defaults to 25. Ignored if event_id is provided."

addedInput schema / properties / page_token

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Token for the next page, taken from a previous response. When single_events=True, also pass the response's Pagination time_min as time_min, even if omitted on the first call. Keep all other query parameters unchanged. Ignored if event_id is provided."
+}

Changed3 schema fields changedv1.25.2Aug 30, 2026

changedInput schema / properties / detailed / description

Previous value: -"Whether to return detailed event information including description, location, colour (colorId), attendees, and attendee details (response status, organizer, optional flags). Recurring instances also report the parent series ID needed to edit the whole series, and events that are not ordinary confirmed meetings report their event type (outOfOffice, workingLocation, focusTime) and status. Defaults to False."New value: +"Whether to return detailed event information including description, location, colour (colorId), attendees, and attendee details (response status, organizer, optional flags). Recurring instances also report the parent series ID needed to edit the whole series; recurring masters report their raw RFC5545 recurrence rules; and events that are not ordinary confirmed meetings report their event type (outOfOffice, workingLocation, focusTime) and status. Defaults to False."

addedInput schema / properties / single_events

Added value: +{
+  "default": true,
+  "description": "Whether to expand recurring series into individual instances. Defaults to True for backwards compatibility. Set to False with detailed=True to retrieve recurring master events and their exact RFC5545 recurrence rules instead of inferring cadence from expanded instances.",
+  "type": "boolean"
+}

changedInput schema / properties / time_min / description

Previous value: -"The start of the time range (inclusive) in RFC3339 format (e.g., '2024-05-12T10:00:00Z' or '2024-05-12'). If omitted, defaults to the current time. Ignored if event_id is provided."New value: +"The start of the time range (inclusive) in RFC3339 format (e.g., '2024-05-12T10:00:00Z' or '2024-05-12'). If omitted, defaults to the current time when single_events=True. It is omitted from unexpanded queries so recurring masters that began in the past but still have future occurrences remain discoverable. Ignored if event_id is provided."

Changed19 schema fields changedv1.0.1Jul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / calendar_id / description

Added value: +"The ID of the calendar to query. Use 'primary' for the user's primary calendar. Defaults to 'primary'. Calendar IDs can be obtained using `list_calendars`."

removedInput schema / properties / calendar_id / title
```
Removed value: -"Calendar Id"
```

addedInput schema / properties / detailed

Added value: +{
+  "default": false,
+  "description": "Whether to return detailed event information including description, location, colour (colorId), attendees, and attendee details (response status, organizer, optional flags). Recurring instances also report the parent series ID needed to edit the whole series, and events that are not ordinary confirmed meetings report their event type (outOfOffice, workingLocation, focusTime) and status. Defaults to False.",
+  "type": "boolean"
+}

addedInput schema / properties / event_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The ID of a specific event to retrieve. If provided, retrieves only this event and ignores time filtering parameters."
+}

addedInput schema / properties / include_attachments

Added value: +{
+  "default": false,
+  "description": "Whether to include attachment information in detailed event output. When True, shows attachment details (fileId, fileUrl, mimeType, title) for events that have attachments. Only applies when detailed=True. Set this to True when you need to view or access files that have been attached to calendar events, such as meeting documents, presentations, or other shared files. Defaults to False.",
+  "type": "boolean"
+}

addedInput schema / properties / max_results / description

Added value: +"The maximum number of events to return. Defaults to 25. Ignored if event_id is provided."

removedInput schema / properties / max_results / title
```
Removed value: -"Max Results"
```

addedInput schema / properties / query

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A keyword to search for within event fields (summary, description, location). Ignored if event_id is provided."
+}

removedInput schema / properties / service

Removed value: -{
-  "title": "service",
-  "type": "string"
-}

addedInput schema / properties / time_max / description

Added value: +"The end of the time range (exclusive) in RFC3339 format. If omitted, events starting from `time_min` onwards are considered (up to `max_results`). Ignored if event_id is provided."

removedInput schema / properties / time_max / title
```
Removed value: -"Time Max"
```

addedInput schema / properties / time_min / description

Added value: +"The start of the time range (inclusive) in RFC3339 format (e.g., '2024-05-12T10:00:00Z' or '2024-05-12'). If omitted, defaults to the current time. Ignored if event_id is provided."

removedInput schema / properties / time_min / title
```
Removed value: -"Time Min"
```
addedInput schema / properties / user_google_email / description
```
Added value: +"The user's Google email address. Required."
```
removedInput schema / properties / user_google_email / title
```
Removed value: -"User Google Email"
```

changedInput schema / required

Previous value: -[
-  "service",
-  "user_google_email"
-]New value: +[
+  "user_google_email"
+]

removedInput schema / title
```
Removed value: -"get_eventsArguments"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}

First observedv1.0.0Jun 10, 2025

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds scoping behavior (single vs. range vs. keyword), but does not disclose pagination behavior, recurring-event expansion nuances, or behavior when no events match. 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.

Conciseness5/5

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

Three short sentences with the primary action front-loaded, followed by the key retrieval variants. There is no filler, no restating of the tool name, and every sentence earns its place.

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?

Given the rich 100%-covered schema, strong annotations, and the presence of an output schema, the high-level description is sufficient for an agent to recognize and begin invoking the tool. It could additionally orient agents toward pagination or recurring-series behavior, but those details are already documented in the schema, so the gap is minor.

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%, and the schema already provides detailed semantics for parameters like query, time_min, single_events, page_token, and detailed. The description only restates that query enables keyword search, adding no meaningful semantic information beyond the schema, so the baseline of 3 applies.

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 and resource ('Retrieves events from a specified Google Calendar') and then enumerates the retrieval modes: single event by ID, multiple events in a time range, and keyword search. This makes the tool's purpose immediately clear and distinguishes it from calendar metadata tools like list_calendars and mutation tools like manage_event.

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

Usage Guidelines3/5

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

The description implies when to use the tool (whenever calendar events need to be read), but it does not explicitly contrast it with sibling tools such as query_freebusy, list_calendars, or manage_event. There is no when-not-to-use guidance or explicit alternative routing, so usage context is only implied.

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

Deploy Server