Did My Calendar Agent Create the Meeting Twice?

A timeout after create_eventis not proof that Google rejected the meeting. The request might have completed after the client stopped waiting. Don't let an agent repeat an attendee-facing write just because the first response went missing.

What the current tool actually sends

CalendarMCP's create_event calls Google's events.insertwith the event details but no caller-supplied event ID. Google generates an ID. The tool returns that ID after a successful response, but a timed-out caller cannot assume it received or retained the response. There is no idempotency key in this tool's input.

Google's event creation guide describes caller-generated IDs as a way to prevent duplicates when an insert succeeds but the response fails. That API option is not exposed by CalendarMCP's currentcreate_event. Don't describe this integration as exactly-once delivery.

A safer recovery sequence

1. Stop automatic retries. Record the intended calendar ID, title, start, end, and attendees from the attempted request.
2. Use list_events on that specific calendar with a narrow, explicit time window and no text query. Increase maxResults or follow its page token if the window is crowded.
3. Check candidate events with get_event. Compare the actual time, organizer, and attendees, not only the title. An existing similar meeting may be unrelated.
4. If you still cannot establish whether the insert landed, ask a person to inspect the calendar before issuing another create call.

This is a read-first containment procedure, not a guarantee that a delayed write cannot appear later. For a workflow that must withstand automatic retries, use a Calendar API integration that persists a valid caller-generated event ID and reconciles the result. The existing timeout guide covers client and server deadlines; the question here is what to do after the result is already ambiguous.