Server has 4 tools with basic verb-noun naming (list_*, create_*, delete_*). All tools have descriptions (10-50 chars), but most are too brief to guide LLM selection effectively. Input schemas are present with type definitions and parameter descriptions, but lack critical constraints (enums, ranges, validation rules). Output schemas are undocumented, LLMs cannot predict return structure. Error handling is absent; no recovery guidance or actionable error messages. create_event and delete_event lack required parameter validation and confirmation patterns for destructive operations. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels.

• Add output schema documentation for each tool. Example: list_calendars returns {items: [{id, summary, description, ...}], nextPageToken?}. Document all fields LLMs need for downstream calls.
• Expand tool descriptions to 100-200 chars. Include WHEN to use, dependencies, and side effects. Example: 'List all calendars you have access to. Call this first to discover calendar IDs before listing events. Returns calendar metadata including timezone and access level.'
• Add tool annotations: @mcp.tool(readOnlyHint=True) for list_*, @mcp.tool(destructiveHint=True) for delete_event. Clients use these to gate dangerous operations.
• Implement confirmation pattern for delete_event: add a dry_run parameter or require explicit event_id validation. Return 'Event deleted: {event_id} from {calendar_id}' with confirmation details.
• Add parameter constraints and validation: start_time/end_time should document ISO 8601 format with timezone examples. Add max_results bounds (1-2500). Validate calendar_id is not empty before API call.