Loading ToolBench
MCP Server for Google Calendar that exposes Google Calendar functionality through the Model Context Protocol
Server has 7 tools with complete input schemas and descriptions present for all tools and parameters. Naming follows verb_noun convention (list_, get_, create_, search_, delete_, update_, check_). However, descriptions are generic and lack LLM-optimization guidance (e.g., 'List upcoming calendar events' vs 'Retrieve upcoming calendar events for the next N days to help plan the user's schedule'). Parameter descriptions are minimal (e.g., 'Event title/summary' lacks format/constraint details). Output schemas are not documented, callers cannot predict response structure. Error handling is absent from visible code. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Composition is sound, each tool has one responsibility. Missing: pagination guidance for list_events, confirmation pattern for delete_event, and recovery hints in error paths.
Check if a time slot is free or busy
Create a new calendar event
Delete a calendar event by ID
Get all events scheduled for today
List upcoming calendar events
Search for events by keyword
Update an existing calendar event
Output schemas not documented. Callers cannot predict response structure (e.g., does list_events return event objects with id, summary, start, end fields?). LLMs cannot plan downstream tool calls without knowing what fields to extract.
Tool descriptions lack LLM-optimization guidance. Generic descriptions like 'List upcoming calendar events' do not explain WHEN to use this tool vs alternatives, WHAT it returns, or WHAT prerequisites exist. Descriptions should be 50-200 chars and answer: what, when, why.
No tool annotations despite clear risk levels. delete_event is DESTRUCTIVE but has no destructiveHint. create_event and update_event are WRITE but lack idempotentHint. list_events, get_today_events, search_events, check_availability are READ_ONLY but lack readOnlyHint. Annotations guide agent safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
delete_event lacks confirmation/dry-run pattern. Irreversible operations should support a confirmation step to prevent accidental deletion. No error recovery guidance visible in code.
Parameter descriptions lack format/constraint details. E.g., 'start_time' and 'end_time' say 'ISO format (e.g., 2024-01-15T10:00:00)' but do not specify timezone handling, whether seconds are required, or what happens if end_time < start_time. LLMs need explicit constraints to avoid invalid input.