Loading ToolBench
Read/search/write iCloud calendars via CalDAV with robust DELETE/ETag handling
The server provides 5 well-named calendar tools with clear, actionable descriptions (150-250 chars each) and complete input schemas. Naming follows verb-noun conventions (list_, search_, create_, update_, delete_). All parameters have type definitions and descriptions. However, output schemas are not documented in the code provided, parameter descriptions lack some format/constraint details, and error handling is minimal. The implementation shows competence but lacks polish expected of production tools.
Create a new event in an iCloud calendar
Delete an event from an iCloud calendar with robust ETag handling
List all available iCloud calendars that support VEVENT
Search for events within a date range, optionally filtering by text pattern
Update an existing event in an iCloud calendar with robust ETag handling
Output schemas not documented. Tool descriptions state what the tool does but do not describe what it returns (field names, types, structure). LLMs cannot plan downstream calls or extract data without knowing the response format.
Parameter descriptions lack format constraints and examples. E.g., 'start_date' and 'end_date' say 'ISO8601 format, UTC assumed if no timezone' but do not clarify whether times are required (2024-01-15 vs 2024-01-15T14:30:00Z). LLMs frequently produce invalid formats.
create_event description mentions 'dtstart' and 'dtend' but does not clarify if all-day events are supported or how to specify them. Timezone handling is mentioned but the interaction between 'tz' param and ISO8601 date parsing is not fully explained.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
No error recovery guidance in tool descriptions. E.g., 'delete_event' description does not explain what happens if the event UID is invalid or the event no longer exists. No guidance for agents on retry strategies or next steps.
search_events 'limit' parameter defaults to 100 but has no min/max bounds in the schema. Unbounded parameters risk LLMs passing absurd values (limit=10000) that could timeout or exhaust memory.
Tool descriptions do not document pagination or result truncation behavior. If search_events returns 100 events max, this should be stated in the description so agents know to iterate with date ranges if needed.