MCP server for calendar event management with AI-powered natural language interaction
This server has critical gaps across naming, descriptions, and schemas. Tool names lack action verbs (list_events, add_event are acceptable, but move_event and change_color are vague). Parameter descriptions are minimal (1-3 words). Input schemas exist but lack detail: no enums for color, no format constraints for date/time strings, no min/max bounds. Output schemas are undocumented. Error handling is absent, tools return bare strings like 'Event not found' with no recovery guidance. No validation of date/time formats, no pagination support despite potential for large event lists. The server treats all parameters as free-form strings, inviting invalid input from LLMs.
Add a new calendar event with title, date, time, and color
Change the color of a calendar event
Delete a calendar event by event ID
List all calendar events
Move a calendar event to a new date and time
No input validation or format constraints. Date and time parameters accept any string; color accepts any string. LLMs will pass invalid values like '2024-13-45' or 'ultraviolet' without constraint feedback.
Error responses are bare strings ('Event not found', 'Deleted event X') with no recovery guidance. LLMs cannot determine if an error is retryable, user-fixable, or fatal.
Parameter descriptions are 1 - 3 words ('Event title', 'Event date', 'Event color'). Baseline is 72 chars. No guidance on format, constraints, or when to use each tool.
Output schemas are undocumented. Callers do not know what fields to expect from add_event, move_event, or change_color. This breaks tool chaining and forces LLMs to guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
No pagination or result limits. list_events returns all events as a raw JSON array. If the calendar grows to thousands of events, the response will exhaust context windows.