gcal

respond_to_event

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).

Input Schema

TableJSON 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 10, 2026

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.

All gcal tools Inspect

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.