Server defines 6 tools with basic schemas and descriptions. All tools have descriptions (10-50 chars, mostly adequate) and input schemas with type definitions. However, descriptions are terse and lack context for LLM selection. Parameter descriptions are minimal. No output schemas documented. Error handling is absent from tool definitions. Tool naming follows verb_noun convention (list_, get_, search_, add_, read_, write_) which is good, but descriptions do not explain WHEN to use each tool or what distinguishes similar tools (e.g., list_events vs search_events). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. write_to_csv_file lacks confirmation/dry-run pattern for destructive operation.

• Rename 'addNumbers' to 'add_numbers' to follow verb_noun convention consistently across all tools.
• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it, and how it differs from similar tools. E.g., 'list_events: Retrieve upcoming calendar events in a time range. Use this for overview queries. For targeted searches by keyword, use search_events instead.'
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. E.g., list_events returns {events: [{id, summary, start, end}], total_count: int}.
• Add tool annotations: mark list_events, get_event_details, search_events, read_from_csv_file as readOnlyHint=true; mark write_to_csv_file as destructiveHint=true.
• Implement error handling with recovery guidance. E.g., if write_to_csv_file fails due to permission, return 'Permission denied: cannot write to /path/file.csv. Check file permissions or choose a different path.' instead of a stack trace.

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

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