domains / agent-tooling / google-calendar-automation / google-calendar-automation

google-calendar-automation

Skill card

combined

The two copies describe the same task but are built on different foundations. The first copy is a concrete implementation guide for a specific MCP server (Rube/Composio), providing exact tool names, parameter constraints (like ISO 8601 vs RFC3339), and specific pitfalls. The second copy is a generic, security-focused policy guide that explicitly warns against assuming a specific integration and emphasizes authorization, least privilege, and verification. Because the first copy's specific tool names would be invalid in the second copy's generic context, and the second copy's security constraints are missing from the first, crowning one would hide a real alternative approach (specific implementation vs. generic secure policy).

Repositories

Other copies

Combined skill

# Google Calendar Automation

## Prerequisites
- An authenticated Google Calendar integration is available (e.g., via MCP or API client).
- If using a specific MCP like Rube, verify the connection is ACTIVE.
- Never request or echo passwords, cookies, or OAuth secrets in chat.

## Workflow
1. **Discovery & Verification**: Inspect the available tools and their schemas. Do not assume tool names. Confirm the account, calendar ID, and IANA timezone.
2. **Read & Resolve**: Read relevant calendars with bounded results. Resolve ambiguous relative dates and daylight-saving changes. Distinguish all-day from timed events.
3. **Draft & Authorize**: Prepare the proposed event details (title, start/end, attendees). For writes, confirm explicit authorization for the specific change and its notification effects. A request to inspect availability does not authorize creating an event.
4. **Execute**: Execute the approved operation once. If using specific tools (e.g., Rube), adhere to their parameter constraints (e.g., ISO 8601 for start times, IANA for timezones, max 59 for duration minutes). On timeout, read state before retrying to avoid duplicates.
5. **Verify**: Read back the resulting event. Report the observed state, event ID, and timezone. State uncertainty if notification delivery cannot be confirmed.

## Pitfalls
- `start_datetime` must be ISO 8601; natural language is rejected.
- `event_duration_minutes` max is 59; use hours for longer durations.
- `timezone` must be IANA identifier; abbreviations like 'EST' are invalid.
- `attendees` only accepts email addresses.
- `PATCH_EVENT` attendees field replaces the entire list; include existing attendees to avoid removal.
- UTC timestamps may not align with local dates; use local timezone offsets for queries.