Four tools with complete schemas and descriptions, but quality is uneven. Naming follows verb_noun convention (list_, create_, delete_, update_). Descriptions are present but generic, most lack context on WHEN to use the tool or what happens on failure. Parameters are typed and mostly described, but lack constraints (enums, ranges, patterns). Output schemas are not documented. Error handling is absent from visible code. The server delegates to a services module, so actual error behavior is opaque.

• Expand delete_event description to 100+ chars: 'Permanently deletes a calendar event by ID. This action cannot be undone. Verify the event_id before calling. Returns success or error with reason (e.g., event not found, permission denied).'
• Document output schemas for all tools. Example for list_events: 'Returns {events: [{id, summary, start, end, location, description}], total_count: int}'. For create_event: 'Returns {event_id, summary, start, end, created_at}'.
• Add constraint guidance to timeZone: 'Must be a valid IANA timezone (e.g., Europe/Zurich, America/New_York, Asia/Tokyo). Invalid values will cause creation to fail.'
• Clarify timeMin/timeMax semantics: 'timeMin filters events that END after this time; timeMax filters events that START before this time. Both are ISO 8601 with timezone offset (e.g., 2025-04-06T10:00:00-07:00).'
• Add error recovery hints to descriptions: 'If creation fails with 'invalid timezone', verify the timezone parameter matches IANA database. If 'permission denied', ensure Google Calendar API is enabled and credentials are valid.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry