Loading ToolBench
Server has 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (list-, create-, update-, delete-). Schemas are well-structured with proper types and nested objects. However, descriptions are generic (10-50 chars) and lack context about when to use each tool or what happens on failure. Parameter descriptions exist but are minimal. Output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Composition is sound, tools are single-purpose and chainable via IDs.
Create a new calendar event
Delete a calendar event
List all available calendars
List events from a calendar
Update an existing calendar event
Tool descriptions are too brief (10-50 chars) and lack context. 'List all available calendars' does not explain when to call this vs list-events, what structure is returned, or whether it requires authentication. LLMs cannot reliably select the right tool without richer guidance.
Output schemas are not documented. Callers do not know what fields list-calendars or list-events return, making it impossible to plan downstream tool calls or extract required IDs (e.g., calendarId for create-event).
No tool annotations despite clear risk levels. delete-event is DESTRUCTIVE but lacks destructiveHint. list-calendars is READ_ONLY but lacks readOnlyHint. Agents cannot distinguish safe from dangerous operations without explicit annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No error handling guidance. If create-event fails due to invalid timezone or attendee email, the response does not tell the LLM what to do next. No recovery hints, no categorization (retryable vs user-fixable).
list-events lacks pagination parameters (limit, offset, pageToken). Returning all events for a calendar could blow the context window. No documented result limit or next_cursor mechanism.