What to Do When a Calendar Batch Update Partly Fails

A partial batch_update_events result means some event patches succeeded while others reported failures. Do not repeat the whole request. Record the event IDs in each outcome, read back uncertain events, and prepare a new request for only the changes still needed.

One tool call is not one transaction

CalendarMCP accepts up to 50 event patches per call on one writable calendar. Its implementation runs up to ten Google Calendar events.patch requests concurrently, then reports successful and failed event IDs separately. It does not call a Google server-side batch endpoint or roll back successful patches if another one fails. The older batch-update overview describes the use case; this distinction matters when building recovery logic.

The tool sets isError only when every patch failed. A mixed result can therefore look successful to a client that inspects only that flag. Read the human-readable summary even when the tool call itself succeeded. It contains X succeeded, Y failed, followed by IDs and error text, not a structured per-event receipt.

Recover by event ID, not by repeating the prompt

1. Keep the original target calendarId, requested patch, and event ID for each row. Ask a person to confirm the proposed set before the first write.
2. After the call, parse the reported successes and failures. For a timeout or lost response, treat every outcome as unknown until checked; do not assume the batch did nothing.
3. Call get_event for any failed or uncertain ID on the same calendar, and compare the relevant fields with the requested values. If an event cannot be read, stop and investigate the permission or ID rather than guessing.
4. Retry only the still-missing changes after correcting the cause. Recheck the final event state before telling the user the job is complete.

As a hypothetical example, if two titles changed and a third event returns a permission error, leave the changed titles alone. Verify the third event and its calendar grant before any retry. This is a recovery procedure derived from thepublished tool contract and implementation, not a report of a customer batch run.

Automatic retries still leave an outcome to verify

CalendarMCP retries individual PATCH requests up to three attempts for HTTP 429, 5xx, and Google rate-limit reasons. It does not retry every kind of error. A client timeout or interrupted response cannot prove which writes reached Google. Google's Events: patch reference documents the per-event partial update, not atomicity across this tool's separate requests. For time changes, pause for human review before retrying: a repeated calendar write can have effects beyond the fields in the final readback.