gcal

Name: gcal
Author: mintmcp

Server Details

A MCP server that works with Google Calendar to manage event listing, reading, and updates.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 50.5% over 37 days
OAuth: Works in Glama
Last Tested: 2026-09-23 15:50
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: mintmcp/servers
GitHub Stars: 8

TDQS

A4.5/5.0

Scored 2026-09-11 07:56 across 7 tools

Disambiguation5/5

Each tool targets a distinct action+resource: create/update/delete/get events, availability lookup, calendar listing, and RSVP. The descriptions explicitly resolve the one risky overlap (respond_to_event vs update_event) by warning users to prefer one over the other, so boundaries are crystal clear.

Naming Consistency4/5

Predominantly a verb_noun pattern (create_event, delete_event, update_event, list_calendars), which is predictable and readable. Minor structural deviations (get_calendar_events, get_next_availability, respond_to_event) vary in shape but stay in the same snake_case verb-first family.

Tool Count5/5

Seven tools is well-scoped for a calendar server, covering the full event lifecycle plus availability and calendar discovery without redundancy. Every tool earns its place.

Completeness4/5

Full CRUD on events (create/get/update/delete) plus availability, calendar listing, and RSVP covers the core calendar domain well. Minor gaps exist around calendar-level management and event search, but agents can work around these.

Available Tools

7 tools

create_eventAInspect

Create a new calendar event. Use this to schedule meetings, appointments, or all-day events. For all-day events, only provide dates (end date is EXCLUSIVE - use '2024-01-16' for a single day event on Jan 15). For timed events, both start and end times are required. Can optionally invite attendees with email notifications. The created event ID can be used for future updates or deletion.

ParametersJSON Schema

Name	Required	Description	Default
`endDate`	Yes	End date YYYY-MM-DD. For all-day: next day. For timed: same or later day
`endTime`	No	End time HH:MM:SS (e.g., "15:00:00"). Required if startTime provided
`summary`	Yes	Event title
`location`	No	Event location (address or meeting room)
`timeZone`	Yes	Timezone (e.g., "America/Los_Angeles", "UTC", "Europe/London")
`attendees`	No	Email addresses of attendees to invite
`startDate`	Yes	Start date YYYY-MM-DD (e.g., "2024-01-15")
`startTime`	No	Start time HH:MM:SS (e.g., "14:00:00"). Omit for all-day events
`calendarId`	Yes	Calendar ID from list_calendars (required - get ID first using list_calendars)
`description`	No	Event description. Supports markdown formatting
`sendUpdates`	No	all: notify everyone, externalOnly: only external users, none: no notifications	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`end`	Yes
`start`	Yes
`status`	No
`summary`	Yes
`htmlLink`	No
`location`	No
`attendees`	No
`description`	No
`hangoutLink`	No
`conferenceData`	No

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), description discloses key behaviors: all-day events only need dates, timed events require both start and end times, attendee invitations possible, and sendUpdates controls notifications. No contradictions 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.

Conciseness4/5

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

Description is a single paragraph with clear front-loading of purpose. It is well-organized but slightly lengthy; still every sentence adds value, so minor deduction for potential slight wordiness.

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?

Given 11 parameters, 100% schema coverage, and an output schema, the description covers all essential aspects: purpose, use-case differentiation, parameter behavior, edge cases, and inter-tool dependencies. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, description adds critical semantics: clarifies that endDate for all-day is exclusive ('use '2024-01-16' for a single day on Jan 15'), explains that startTime is omitted for all-day events, and specifies that calendarId comes from list_calendars. This goes beyond the schema.

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?

Description explicitly states 'Create a new calendar event' and lists specific use cases (meetings, appointments, all-day events). It clearly distinguishes from sibling tools like update_event and delete_event by mentioning the returned event ID for future updates/deletions.

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 detailed usage guidance: when to use all-day vs timed events, required fields for each case, and the exclusive end date nuance. Also links to list_calendars for obtaining calendarId and notes that created ID enables future operations.

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

delete_eventA

Destructive

Inspect

Permanently delete an event by eventId (no undo). Sends cancellation notifications to attendees by default (control with sendUpdates). Returns {success: true, eventId, message} on success.

ParametersJSON Schema

Name	Required	Description	Default
`eventId`	Yes	Event ID to delete
`calendarId`	Yes	Calendar ID from list_calendars
`sendUpdates`	No	Whether to send cancellation notifications (all: notify all attendees, externalOnly: only non-Google Calendar users, none: no notifications)	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`eventId`	Yes
`message`	Yes
`success`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating 'permanently delete' and 'no undo'. It adds valuable context beyond annotations: default behavior of sending cancellation notifications and the ability to control it via sendUpdates, though it doesn't mention rate limits or auth needs.

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?

The description is front-loaded with the core action and key details ('permanently delete', 'no undo', notifications), followed by return value info. Every sentence adds value without redundancy, making it efficient and well-structured.

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?

Given the presence of annotations (destructiveHint, readOnlyHint), a rich input schema with 100% coverage, and an output schema (implied by return value description), the description is complete. It covers the tool's behavior, key parameters, and output, leaving no significant gaps for a deletion tool.

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?

With 100% schema description coverage, the schema fully documents parameters like eventId, calendarId, and sendUpdates with enum details. The description adds minimal semantics by mentioning eventId and sendUpdates control, but doesn't provide extra meaning beyond the schema's thorough descriptions.

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 clearly states the specific action ('permanently delete') and resource ('an event by eventId'), distinguishing it from siblings like update_event or create_event. It explicitly mentions the irreversible nature ('no undo'), which further clarifies its purpose.

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

Usage Guidelines4/5

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

The description implies usage for deleting events, with context from siblings suggesting alternatives like update_event for modifications or get_calendar_events for viewing. However, it lacks explicit guidance on when to use this tool versus others (e.g., no mention of prerequisites like needing eventId from list operations).

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

get_calendar_eventsA

Read-only

Inspect

Retrieve events from a specific calendar within a time range. Use this to view scheduled events, check availability, or find specific appointments. Times are interpreted in the provided timezone. Without dateMax, returns all future events from dateMin. IMPORTANT: For single day events, use next day as dateMax (e.g., dateMin='2024-01-15' and dateMax='2024-01-16'). Event IDs from this tool are required for update/delete operations.

ParametersJSON Schema

Name	Required	Description
`dateMax`	No	End date YYYY-MM-DD. Events BEFORE this date. For single day, use next day
`dateMin`	Yes	Start date YYYY-MM-DD (e.g., "2024-01-15"). Required
`timeMax`	No	End time HH:MM:SS. Only valid with dateMax
`timeMin`	Yes	Start time HH:MM:SS (e.g., "09:00:00"). Required
`timeZone`	Yes	Timezone for interpreting dates/times (e.g., "America/Los_Angeles", "UTC")
`pageToken`	No	Pagination token from previous response
`calendarId`	Yes	Calendar ID from list_calendars (required - get ID first using list_calendars)
`maxResults`	No	Number of events to return (1-2500). Default: 10

Output Schema

ParametersJSON Schema

Name	Required	Description
`events`	Yes
`message`	No
`calendarId`	Yes
`nextPageToken`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and non-destructive. The description adds behavioral details: timezone interpretation, default behavior without dateMax (returns all future events), and pagination via pageToken. No contradictions 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.

Conciseness4/5

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

The description is concise (5 sentences) and front-loaded with purpose. Every sentence adds value, including the note about event IDs. Slight improvement could be to remove redundancy with schema, but overall efficient.

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 tool has an output schema, return value explanation is not needed. The description covers usage, parameters, timezone handling, pagination, and the important single-day event tip. Lacks mention of rate limits or error conditions, but these are not critical for a read-only tool.

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?

Schema coverage is 100%; all parameters have descriptions. The description adds value by explaining calendarId source (list_calendars) and providing a usage note for dateMax. It also reinforces that timeMin and dateMin are required.

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 uses a specific verb ('Retrieve events') and clearly identifies the resource ('from a specific calendar within a time range'). It distinguishes from sibling tools by stating it is for viewing, not creating/deleting/updating events.

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

Usage Guidelines4/5

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

The description provides clear context on when to use: 'view scheduled events, check availability, or find specific appointments'. It also includes an important note about single-day events and links event IDs to update/delete operations. Lacks explicit exclusion of alternatives like get_next_availability.

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

get_next_availabilityA

Read-only

Inspect

Find next 10 available time slots in a calendar. Searches up to 30 days ahead. Returns {availableSlots: [{start, end}...], searchedUntil} with times in the specified timezone. Use searchedUntil with new startFromDate/Time to paginate. Can restrict to specific hours/days. Slots align to startTimeIncrement boundaries.

ParametersJSON Schema

Name	Required	Description
`duration`	Yes	Duration of the meeting in minutes (e.g., 30, 60, 90)
`timezone`	Yes	Time zone for all operations (IANA format, e.g., "America/New_York")
`calendarId`	Yes	Calendar ID from list_calendars
`includeDays`	No	Days of the week to include in search (default: weekdays only)
`startFromDate`	Yes	Start searching from this date in YYYY-MM-DD format (e.g., "2024-01-15")
`startFromTime`	Yes	Start searching from this time in HH:MM:SS format (e.g., "09:00:00")
`searchHoursEnd`	No	Daily search window end time in HH:MM:SS format (e.g., "17:00:00"). If not provided, searches all hours
`searchHoursStart`	No	Daily search window start time in HH:MM:SS format (e.g., "09:00:00"). If not provided, searches all hours
`startTimeIncrement`	No	Increment between possible start times in minutes (e.g., 15 for every 15 minutes, 30 for every half-hour)

Output Schema

ParametersJSON Schema

Name	Required	Description
`searchedUntil`	Yes
`availableSlots`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds valuable behavioral context beyond annotations: the 30-day search limit, pagination mechanism using searchedUntil, slot alignment to startTimeIncrement boundaries, and the ability to restrict to specific hours/days. This significantly enhances understanding of the tool's operational behavior.

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?

The description is efficiently structured in four sentences with zero waste: first states core purpose, second defines search scope and output format, third explains pagination, fourth adds filtering and alignment details. Every sentence contributes essential information without redundancy.

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?

Given the tool's moderate complexity (9 parameters, read-only operation), the description is complete: it explains what the tool does, its constraints (30-day limit), output format, pagination mechanism, and key behavioral details. With annotations covering safety and an output schema presumably documenting the return structure, no critical gaps remain.

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?

With 100% schema description coverage, the input schema already documents all 9 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mentioning timezone specification and startTimeIncrement alignment, but doesn't provide additional syntax or format details. This meets the baseline expectation when schema coverage is complete.

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 clearly states the specific action ('Find next 10 available time slots in a calendar') and resource ('calendar'), distinguishing it from siblings like get_calendar_events (which retrieves existing events) or create_event (which creates events). The verb 'find' with the quantitative '10 available time slots' provides precise scope.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('Find next 10 available time slots') and implies pagination guidance ('Use searchedUntil with new startFromDate/Time to paginate'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (e.g., get_calendar_events for viewing existing events).

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

list_calendarsA

Read-only

Inspect

List all calendars the user has access to. Use this to discover available calendars before performing calendar operations. The primary calendar (primary:true) is the user's main calendar. Other calendars may be shared, subscribed, or secondary calendars. The calendar ID is required for all other calendar operations.

ParametersJSON Schema

Name	Required	Description	Default
`pageToken`	No	Pagination token from previous response to get next page
`maxResults`	No	Number of calendars to return (1-250). Default: 100

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`calendars`	Yes
`nextPageToken`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context beyond annotations by explaining the types of calendars (primary, shared, subscribed, secondary) and the importance of calendar IDs for other operations. However, it does not disclose behavioral traits like pagination details or rate limits, which are partially covered by the input schema but could be elaborated.

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?

The description is front-loaded with the core purpose in the first sentence, followed by usage guidance and additional context. Each sentence earns its place by providing value, such as explaining calendar types and ID requirements, without unnecessary repetition or fluff. It is appropriately sized for the tool's complexity.

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?

Given the tool's low complexity (list operation), rich annotations (read-only, non-destructive), and the presence of an output schema, the description is complete enough. It covers the purpose, usage context, and key behavioral insights (e.g., calendar types and ID importance), without needing to explain return values or detailed parameters, which are handled by structured data.

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%, with clear descriptions for both parameters (pageToken and maxResults). The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how pagination works in practice or default behaviors. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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 clearly states the specific action ('List all calendars') and resource ('calendars the user has access to'), distinguishing it from sibling tools like create_event or get_calendar_events. It explicitly mentions the purpose is to 'discover available calendars before performing calendar operations,' which is distinct from operations that manipulate events or check availability.

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?

The description provides explicit guidance on when to use this tool ('to discover available calendars before performing calendar operations') and implies when not to use it (e.g., for event-related operations handled by siblings). It also notes that 'The calendar ID is required for all other calendar operations,' reinforcing its role as a prerequisite step.

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

respond_to_eventAInspect

RSVP to a calendar event on behalf of the current user only (accept, decline, or tentatively accept). Use this instead of update_event to set your own response — update_event replaces the whole attendee list and wipes everyone else's responses. This tool reads the event, changes ONLY your own responseStatus (matched by your own email address), and preserves every other attendee's response. Always prefer calendarId='primary' - on a shared calendar your attendee entry cannot always be identified safely. For a recurring event, passing the series eventId responds for the ENTIRE series, while passing a single instance ID ('_', e.g. 'abc123_20240115T170000Z') responds for that one occurrence only. Returns the event with your updated response {id, summary, myResponseStatus, myComment, attendees, ...}, where myComment is your currently stored response comment (omitted when you have none).

ParametersJSON Schema

Name	Required	Description	Default
`comment`	No	Optional response comment shown to the organizer
`eventId`	Yes	Event ID to respond to (from get_calendar_events). For a recurring event, the series ID responds for the whole series; a single instance ID ('<eventId>_<UTC timestamp>') responds for that occurrence only
`calendarId`	Yes	Calendar ID the event lives on, from list_calendars. Use 'primary' for your own calendar (required to detect your attendee entry)
`sendUpdates`	No	Whether to notify others of your response (all: notify everyone, externalOnly: only non-Google Calendar users, none: no notifications)	all
`responseStatus`	Yes	Your RSVP: accepted, declined, or tentative

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`end`	Yes
`start`	Yes
`status`	No
`message`	Yes
`summary`	No
`updated`	No
`htmlLink`	No
`attendees`	No
`myComment`	No
`myResponseStatus`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

The description clearly discloses that the tool modifies only the caller's own responseStatus, preserves everyone else's responses, and may fail to locate the attendee entry on non-primary calendars. It also explains recurrence behavior and what the response includes. All of this is consistent with the annotations (readOnlyHint=false, destructiveHint=false).

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?

Every sentence carries distinct information: core operation, relationship to alternatives, safety semantics, calendar guidance, and recurring-event behavior. The most important distinction from update_event is front-loaded.

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?

The description covers the critical behaviors an agent must know: the narrow mutation scope, the shared-calendar pitfall, the calendarId recommendation, recurrence semantics, and the return value. Combined with the 100%-described schema and existing output schema, nothing essential is missing.

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?

The input schema already covers all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds extra value by advising calendarId='primary', explaining the recurring-event ID forms, and clarifying that responseStatus maps to the caller's own email address.

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 names a specific verb and resource: RSVP to a calendar event with accept, decline, or tentative response. It explicitly distinguishes this tool from update_event, making its unique purpose immediately clear.

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 explicitly states when to use this tool instead of update_event ('to set your own response') and warns that update_event replaces the whole attendee list and wipes others' responses. It also gives concrete guidance to prefer calendarId='primary' and explains how recurring event IDs behave.

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

update_eventAInspect

Update an existing event by eventId. Dates/times are interpreted in the provided timezone. Can update individual fields (summary, description, location) OR update times (must provide all: startDate, endDate, and optionally startTime, endTime). WARNING: Empty strings/arrays CLEAR fields. The attendees param REPLACES the entire guest list and resets everyone's RSVP to needsAction — to accept/decline/tentatively respond for yourself, use respond_to_event instead. Cannot move between calendars. Returns updated event {id, summary, start, end, updated, ...}.

ParametersJSON Schema

Name	Required	Description	Default
`endDate`	No	End date in YYYY-MM-DD format (e.g., "2024-01-16" for all-day or "2024-01-15" for timed). Required if updating time
`endTime`	No	End time in HH:MM:SS format (e.g., "15:00:00"). Omit for all-day events
`eventId`	Yes	Event ID to update
`summary`	No	Event title/summary
`location`	No	Event location
`timeZone`	Yes	Timezone for interpreting dates and times (e.g., "America/Los_Angeles", "UTC", "Europe/London")
`attendees`	No	Array of attendee email addresses (replaces existing attendees)
`startDate`	No	Start date in YYYY-MM-DD format (e.g., "2024-01-15"). Required if updating time
`startTime`	No	Start time in HH:MM:SS format (e.g., "14:00:00"). Omit for all-day events
`calendarId`	Yes	Calendar ID from list_calendars
`description`	No	Event description
`sendUpdates`	No	Whether to send update notifications (all: notify all attendees, externalOnly: only non-Google Calendar users, none: no notifications)	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`end`	Yes
`start`	Yes
`status`	No
`summary`	Yes
`updated`	No
`htmlLink`	No
`location`	No
`attendees`	No
`description`	No
`hangoutLink`	No
`conferenceData`	No

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, but the description discloses critical behaviors: dates/times interpreted in provided timezone, empty strings/arrays clear fields, attendees param replaces the entire guest list and resets RSVP, and cannot move between calendars. This goes well beyond annotations and is essential for safe use.

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?

The description is concise yet information-dense. It front-loads the core purpose, then delivers each behavioral nuance in a single sentence per concept: timezone handling, field vs time updates, clearing warning, attendees replacement, calendar constraint, and return format. No filler.

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?

Given 12 parameters and multiple update modes, the description covers all critical decision points and side effects. It explains the time update constraint, clearing behavior, attendee replacement, cross-calendar restriction, and mentions the return object. With an output schema present, nothing essential is missing.

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?

Schema coverage is 100%, so baseline is 3. However, the description adds semantic value by clarifying the all-or-nothing requirement for time updates, the clearing behavior with empty strings, and that attendees replaces the list and resets RSVP. These insights are not fully apparent from the schema alone.

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 clearly states the verb 'Update' with a specific resource 'existing event by eventId'. It also specifies the scope of what can be updated (fields or times) and differentiates from respond_to_event and the inability to move calendars, making it distinct from siblings.

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?

Explicitly provides when to use this tool vs alternatives: 'to accept/decline/tentatively respond for yourself, use respond_to_event instead.' Also specifies the conditions for updating times (must provide all startDate/endDate) and warns about clearing fields with empty strings, giving clear context for correct invocation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 10, 2026
- Addedrespond_to_event

3 tool updatesApr 18, 2026

Changedcreate_event2 fields changed

addedOutput schema / properties / conferenceData

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "conferenceId": {
+      "type": "string"
+    },
+    "conferenceSolution": {
+      "additionalProperties": false,
+      "properties": {
+        "iconUri": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "entryPoints": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "entryPointType": {
+            "type": "string"
+          },
+          "label": {
+            "type": "string"
+          },
+          "uri": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "entryPointType",
+          "uri"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / hangoutLink
```
Added value: +{
+  "type": "string"
+}
```

Changedget_calendar_events2 fields changed

addedOutput schema / properties / events / items / properties / conferenceData

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "conferenceId": {
+      "type": "string"
+    },
+    "conferenceSolution": {
+      "additionalProperties": false,
+      "properties": {
+        "iconUri": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "entryPoints": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "entryPointType": {
+            "type": "string"
+          },
+          "label": {
+            "type": "string"
+          },
+          "uri": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "entryPointType",
+          "uri"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / events / items / properties / hangoutLink
```
Added value: +{
+  "type": "string"
+}
```

Changedupdate_event2 fields changed

addedOutput schema / properties / conferenceData

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "conferenceId": {
+      "type": "string"
+    },
+    "conferenceSolution": {
+      "additionalProperties": false,
+      "properties": {
+        "iconUri": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "entryPoints": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "entryPointType": {
+            "type": "string"
+          },
+          "label": {
+            "type": "string"
+          },
+          "uri": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "entryPointType",
+          "uri"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / hangoutLink
```
Added value: +{
+  "type": "string"
+}
```

6 tool updatesApr 7, 2026
- Changedcreate_event8 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedOutput schema / properties / attendees / items / properties / responseStatus / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / attendees / items / properties / responseStatus / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
  - removedOutput schema / properties / end / $ref
```
Removed value: -"#/properties/start"
```
  - addedOutput schema / properties / end / additionalProperties
```
Added value: +false
```
  - addedOutput schema / properties / end / properties
```
Added value: +{
+  "date": {
+    "type": "string"
+  },
+  "dayOfWeek": {
+    "type": "string"
+  },
+  "time": {
+    "type": "string"
+  },
+  "timezone": {
+    "type": "string"
+  }
+}
```
  - addedOutput schema / properties / end / required
```
Added value: +[
+  "date",
+  "dayOfWeek"
+]
```
  - addedOutput schema / properties / end / type
```
Added value: +"object"
```
- Changeddelete_event1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Changedget_calendar_events14 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedOutput schema / properties / events / items / properties / attendees / items / properties / responseStatus / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / events / items / properties / attendees / items / properties / responseStatus / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
  - addedOutput schema / properties / events / items / properties / description / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / events / items / properties / description / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
  - removedOutput schema / properties / events / items / properties / end / $ref
```
Removed value: -"#/properties/events/items/properties/start"
```
  - addedOutput schema / properties / events / items / properties / end / additionalProperties
```
Added value: +false
```
  - addedOutput schema / properties / events / items / properties / end / properties
```
Added value: +{
+  "date": {
+    "type": "string"
+  },
+  "dayOfWeek": {
+    "type": "string"
+  },
+  "time": {
+    "type": "string"
+  },
+  "timezone": {
+    "type": "string"
+  }
+}
```
  - addedOutput schema / properties / events / items / properties / end / required
```
Added value: +[
+  "date",
+  "dayOfWeek"
+]
```
  - addedOutput schema / properties / events / items / properties / end / type
```
Added value: +"object"
```
  - addedOutput schema / properties / events / items / properties / location / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / events / items / properties / location / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
  - addedOutput schema / properties / nextPageToken / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / nextPageToken / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- Changedget_next_availability6 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedOutput schema / properties / availableSlots / items / properties / end / $ref
```
Removed value: -"#/properties/availableSlots/items/properties/start"
```
  - addedOutput schema / properties / availableSlots / items / properties / end / additionalProperties
```
Added value: +false
```
  - addedOutput schema / properties / availableSlots / items / properties / end / properties
```
Added value: +{
+  "date": {
+    "type": "string"
+  },
+  "dayOfWeek": {
+    "type": "string"
+  },
+  "time": {
+    "type": "string"
+  },
+  "timezone": {
+    "type": "string"
+  }
+}
```
  - addedOutput schema / properties / availableSlots / items / properties / end / required
```
Added value: +[
+  "date",
+  "dayOfWeek"
+]
```
  - addedOutput schema / properties / availableSlots / items / properties / end / type
```
Added value: +"object"
```
- Changedlist_calendars3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedOutput schema / properties / nextPageToken / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / nextPageToken / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- Changedupdate_event8 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedOutput schema / properties / attendees / items / properties / responseStatus / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / attendees / items / properties / responseStatus / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
  - removedOutput schema / properties / end / $ref
```
Removed value: -"#/properties/start"
```
  - addedOutput schema / properties / end / additionalProperties
```
Added value: +false
```
  - addedOutput schema / properties / end / properties
```
Added value: +{
+  "date": {
+    "type": "string"
+  },
+  "dayOfWeek": {
+    "type": "string"
+  },
+  "time": {
+    "type": "string"
+  },
+  "timezone": {
+    "type": "string"
+  }
+}
```
  - addedOutput schema / properties / end / required
```
Added value: +[
+  "date",
+  "dayOfWeek"
+]
```
  - addedOutput schema / properties / end / type
```
Added value: +"object"
```

6 tool updatesFeb 9, 2026

Changedcreate_event1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "attendees": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "email": {
+            "type": "string"
+          },
+          "responseStatus": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "email"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "description": {
+      "type": "string"
+    },
+    "end": {
+      "$ref": "#/properties/start"
+    },
+    "htmlLink": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "location": {
+      "type": "string"
+    },
+    "start": {
+      "additionalProperties": false,
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "dayOfWeek": {
+          "type": "string"
+        },
+        "time": {
+          "type": "string"
+        },
+        "timezone": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "date",
+        "dayOfWeek"
+      ],
+      "type": "object"
+    },
+    "status": {
+      "type": "string"
+    },
+    "summary": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "summary",
+    "start",
+    "end"
+  ],
+  "type": "object"
+}

Changeddelete_event1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "eventId": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "eventId",
+    "message"
+  ],
+  "type": "object"
+}

Changedget_calendar_events1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "calendarId": {
+      "type": "string"
+    },
+    "events": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "attendees": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "email": {
+                  "type": "string"
+                },
+                "responseStatus": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "required": [
+                "email"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "description": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "end": {
+            "$ref": "#/properties/events/items/properties/start"
+          },
+          "htmlLink": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "location": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "start": {
+            "additionalProperties": false,
+            "properties": {
+              "date": {
+                "type": "string"
+              },
+              "dayOfWeek": {
+                "type": "string"
+              },
+              "time": {
+                "type": "string"
+              },
+              "timezone": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "date",
+              "dayOfWeek"
+            ],
+            "type": "object"
+          },
+          "status": {
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "updated": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "summary",
+          "start",
+          "end"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "nextPageToken": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "calendarId",
+    "events",
+    "nextPageToken"
+  ],
+  "type": "object"
+}

Changedget_next_availability1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "availableSlots": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "end": {
+            "$ref": "#/properties/availableSlots/items/properties/start"
+          },
+          "start": {
+            "additionalProperties": false,
+            "properties": {
+              "date": {
+                "type": "string"
+              },
+              "dayOfWeek": {
+                "type": "string"
+              },
+              "time": {
+                "type": "string"
+              },
+              "timezone": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "date",
+              "dayOfWeek"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "start",
+          "end"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "searchedUntil": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "availableSlots",
+    "searchedUntil"
+  ],
+  "type": "object"
+}

Changedlist_calendars1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "calendars": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "accessRole": {
+            "type": "string"
+          },
+          "description": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "primary": {
+            "type": "boolean"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "timeZone": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "summary",
+          "primary"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "nextPageToken": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "calendars",
+    "nextPageToken"
+  ],
+  "type": "object"
+}

Changedupdate_event1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "attendees": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "email": {
+            "type": "string"
+          },
+          "responseStatus": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "email"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "description": {
+      "type": "string"
+    },
+    "end": {
+      "$ref": "#/properties/start"
+    },
+    "htmlLink": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "location": {
+      "type": "string"
+    },
+    "start": {
+      "additionalProperties": false,
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "dayOfWeek": {
+          "type": "string"
+        },
+        "time": {
+          "type": "string"
+        },
+        "timezone": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "date",
+        "dayOfWeek"
+      ],
+      "type": "object"
+    },
+    "status": {
+      "type": "string"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "updated": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "summary",
+    "start",
+    "end"
+  ],
+  "type": "object"
+}

6 tool updatesJan 31, 2026
- First observedcreate_event
- First observeddelete_event
- First observedget_calendar_events
- First observedget_next_availability
- First observedlist_calendars
- First observedupdate_event

Related MCP Connectors

outlook-calendarOAuth
com.mintmcp
A MCP server that works with Outlook Calendar to manage event listing, reading, and updates.
Calendar Management Communication App Automation
38
google-eventsOAuth
io.github.johnisanerd
Google Events listings with dates, venues, and ticket links via a hosted MCP server.
Calendar Management Location Services
22
CalendarMCP
ai.calendarmcp
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Calendar Management Workplace & Productivity
21
cronofy A
io.usefulapi
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
Calendar Management Workplace & Productivity
82

Related MCP Servers

GoogleCalendarMCP
Calendar Management Workplace & Productivity
umachandra-30
F
license
D
quality
D
maintenance
MCP server for interacting with Google Calendar, enabling reading events from public calendars and, with OAuth, creating, updating, and deleting events.
Updated 3 months ago (2026-06-19 06:07 UTC)
1
-
google-calendar-mcp-lib
Calendar Management Cloud Platforms Workplace & Productivity
appler1009
A
license
Not graded
quality
D
maintenance
A Google Calendar MCP server that enables listing, creating, updating, and deleting calendar events and calendars through natural language.
Updated 7 months ago (2026-03-07 05:48 UTC)
7 npm
ISC
google-calendar-mcp
Calendar Management Workplace & Productivity
YerayRodri
A
license
Not graded
quality
C
maintenance
MCP server for Google Calendar that enables listing, creating, updating, and deleting events, quick-add from natural language, responding to invitations, and checking availability across multiple accounts.
Updated 24 days ago (2026-08-30 18:13 UTC)
MIT
gcal-mcp
Calendar Management App Automation Workplace & Productivity
jdcc
F
license
Not graded
quality
D
maintenance
An MCP server that provides integration with Google Calendar, allowing users to list calendars and manage events. It enables searching, creating, and modifying calendar entries through tools designed for the Model Context Protocol.
Updated 7 months ago (2026-02-19 05:05 UTC)
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources