Loading ToolBench
A calendar server with MCP (Model Context Protocol) support for managing events, calendars, tags, reminders, and image imports
yot-calendar provides 20 well-structured tools with consistent naming (verb_noun pattern) and complete JSON schemas. All tools have descriptions and typed parameters. However, descriptions are minimal (10-30 chars, well below the 50-200 char LLM-optimized baseline), parameter descriptions lack actionable constraints (e.g., date format, enum values), and output schemas are not documented. Error handling is present but generic. No tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications. Composition is sound, tools are single-responsibility and chainable. Security: no secrets in params, but no audit logging visible.
Add a reminder to an event
Create a new calendar
Create a new event
Create a new tag
Delete a calendar
Delete an event
Delete a tag
Descriptions are critically short (10-30 chars vs. 50-200 char LLM-optimized baseline). Examples: 'List all calendars', 'Create a new calendar'. LLMs cannot infer when to select these tools or what distinguishes them from similar operations. Descriptions must explain WHAT, WHEN, and any prerequisites.
Parameter descriptions lack actionable constraints. 'start_time' says 'ISO 8601' but no example or validation guidance. 'color' has no enum or format spec. 'minutes_before' has no min/max bounds. LLMs cannot validate inputs without explicit constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Get a specific event by ID
Get the image associated with an event
Import events from an ICS (iCalendar) file
List all calendars
List events with optional filtering
List all tags
Remove a reminder from an event
Add a tag to an event
Remove a tag from an event
Update an existing calendar
Update an existing event
Update an existing tag
Upload an image from a URL and associate it with an event
Output schemas not documented. Tools return results but LLMs cannot plan downstream calls without knowing response structure. E.g., does create_calendar return {id, name, color} or {calendar: {id, name, color}}? Undocumented responses force LLMs to guess field names.
No tool annotations despite clear risk classifications. delete_calendar, delete_event, delete_tag are marked DESTRUCTIVE but lack destructiveHint annotation. list_* tools are READ_ONLY but lack readOnlyHint. Annotations enable agents to reason about safety and retry logic.
Error handling is generic. No recovery guidance in error responses. If create_event fails due to invalid calendar_id, the error should suggest 'Call list_calendars() first to find a valid ID.' Current implementation returns raw JSON-RPC errors without actionable next steps.