Loading ToolBench
A Model Context Protocol server for macOS Calendar.app that provides an interface to interact with Calendar.app, allowing you to list available calendars, view, create, update, and delete events, search for events by date range, and get detailed information about calendars and events.
Calendar MCP has 11 tools with reasonable naming and mostly complete schemas. Tool names follow verb_noun convention (create_event, delete_event, list_calendars, etc.), which is a strength. Descriptions are present for all tools and most parameters. However, there are systematic gaps: (1) Many parameter descriptions are generic or lack format constraints (e.g., 'start_date' and 'end_date' accept 'flexible format' but no regex or specific examples); (2) Output schemas are not documented in the tool definitions, the code hints at JSON returns but the exact field structure is not declared; (3) No error handling guidance in descriptions; (4) No documentation of which operations are idempotent; (5) Parameter defaults are not always clear (e.g., 'calendar' parameter in search_events is optional with no indication of fallback behavior); (6) No confirmation/dry-run pattern for destructive operations (delete_event, delete_reminder). The codebase shows proper separation of concerns and good resource naming (calendars://list, calendar://{name}), but the tool interface itself lacks production-grade polish in error guidance and output documentation.
Mark a reminder as completed
Create a new event in a calendar
Create a new reminder in a reminder list
Delete an event from a calendar
Delete a reminder from a reminder list
Get events from a specific calendar, optionally filtered by date range
Get reminders from a reminder list, optionally filtered by status and date range
Output schemas not documented. Tool descriptions and code reveal that tools return JSON, but the exact field structure (which fields exist, types, required vs optional) is not declared in the tool definitions. LLMs cannot plan downstream tool calls or extract specific data without knowing the response shape.
Date/time parameter formats lack specificity. Parameters like 'start_date', 'end_date', and 'due_date' accept 'flexible format' or 'flexible format (e.g. 2025-06-08, 2025-06-08 09:00)' but do not declare a formal constraint. LLMs cannot reliably format dates without explicit patterns (ISO 8601, regex). Current descriptions are example-based, which risks LLMs treating examples as the only valid formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 19 | - | v1 |
List all available calendars in Calendar.app
Search for events by query across calendars and optionally within a date range
Update an existing event in a calendar
Update an existing reminder
No error handling guidance. Destructive operations (delete_event, delete_reminder) and write operations (create_*, update_*) have no descriptions indicating what errors could occur, when to retry, or how to recover. Descriptions like 'Delete an event from a calendar' do not guide the LLM on failure modes.
No confirmation/dry-run for destructive operations. delete_event and delete_reminder are irreversible but have no mention of confirmation steps, preview, or dry-run mode. Agents can mistakenly delete data without safeguards.
Optional parameters lack clear defaults. Parameters like 'calendar' in search_events are marked optional with description 'Specific calendar to search in (optional, defaults to all calendars)' but the behavior is not enforced or validated in parameter constraints. If an LLM omits the parameter expecting all calendars to be searched, and the backend falls back to an empty string or single calendar, results will be silently wrong.
Priority enum not documented in parameter. The 'priority' parameter in create_reminder accepts integers (0=None, 1=High, 5=Medium, 9=Low) but this is not formalized as an enum constraint. LLMs will struggle to pick correct values without an explicit enum or pattern rule.
State modification not signaled in tool descriptions. Tools like create_event, delete_event, and update_reminder modify calendar or reminder state, but descriptions do not explicitly state 'This creates/modifies/deletes a calendar event' to help LLMs understand idempotency, retry-safety, and side effects.
Parameter relationships not documented. In tools like update_event, multiple fields (summary, start_date, end_date, location, description) are all optional, but the relationships between them are unclear. Can you update only the location without touching dates? Are start_date and end_date dependent? Undocumented dependencies lead to misuse.