Loading ToolBench
Google Calendar integration MCP server for Claude Desktop with multi-account support, event management, availability checking, project tracking, and contact management
The server defines 7 tools with significant quality gaps. Tool naming is weak (generic action-based design rather than verb_noun clarity), descriptions are minimal or missing detail on several tools, input schemas lack proper JSON Schema structure validation, and error handling is not evident. Most tools aggregate multiple operations under a single 'action' enum parameter, violating the single-responsibility principle. Output schemas are entirely undocumented. This is a community-grade server with below-median definition quality.
Manage attendees and respond to invitations. Actions: list, add, remove, resend, respond
Check availability and find meeting slots. Actions: query (freebusy), find_slots (with timezone support)
Manage calendars, colors, settings, accounts. Actions: list, get, create, update, delete, colors, settings, set_timezone, list_accounts
Contact management (v2 schema). organization_id links to organizations table. Relationship tracking: context, relationship_type, relationship_strength
All event operations. Actions: list, create, get, update, delete, search, batch. For recurring: scope=single|all. For move: destination_calendar_id=...
Project management (v2 schema). Operations: project_*, phase_*, task_*, norm_*, exclusion_*, config_*, report_*. Organizations: org_*, project_org_* (M:N with projects). Hierarchy: PROJECT → PHASE → TASK
Weekly schedule overview
Action-enum anti-pattern: 6 of 7 tools (calendars, availability, events, attendees, projects, contacts) bundle 5 - 8 distinct operations into a single tool with an 'action' enum parameter. This violates the single-responsibility principle (pattern:tool) and forces LLMs to memorize operation lists rather than discovering intent from tool names. Example: 'events' combines list, create, get, update, delete, search, batch, should be 6 - 7 separate tools (list_events, create_event, get_event, update_event, delete_event, search_events, batch_update_events).
Missing output schemas: No tool documents its return type or structure. LLMs cannot plan downstream calls or extract results without knowing the response shape. Pattern 'response-shaper' requires documented output; pattern 'tool-chain' requires that tool_A output includes IDs tool_B needs. This server provides neither.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Weak tool naming: 6 of 7 tools use nouns (calendars, availability, events, attendees, projects, contacts) instead of verb_noun pattern (e.g., list_calendars, query_availability, create_event). Only weekly_brief approaches a verb-like name. Baseline: 90% of A+ tools start with an action verb. This server averages ~40% verb clarity, increasing LLM confusion when many tools are available.
Missing parameter descriptions and conditional logic: Tools like 'events' mention 'scope' and 'destination_calendar_id' as conditional but do not link them to specific actions. Baseline: 100% of A+ tools document all parameter dependencies. Pattern 'constrained-input' requires explicit enum/format constraints. Many parameters are listed without explaining when they are required, what values are valid, or how they interact.
Incomplete tool descriptions: Tools like 'projects' and 'contacts' have descriptions that are either too long and unfocused (projects: 200+ chars listing v2 schema details) or too short (contacts: 60 chars). Baseline: descriptions should be 34 - 392 chars, with an average of 194. Most descriptions here lack WHEN-to-use guidance, dependency hints, and recovery instructions. Pattern 'tool-description' requires explicit context for LLM selection.
Free-form 'action' parameter without enum constraints: Tools 'projects' and 'contacts' define 'action' as a plain string type with no enum, forcing LLMs to guess valid operation names. Pattern 'constrained-input' requires enums for bounded value sets. Even 'events' and 'calendars', which use enums, do not validate them server-side, no error handling visible.
No error handling or recovery guidance: The code excerpt shows OAuth and client setup but does not reveal error handling in tool implementations. Pattern 'recovery-guide' requires that error responses guide the LLM on next steps (retry, lookup alternative, ask user). Pattern 'error-classification' requires distinguishing retryable vs user-fixable vs fatal errors. No visible guidance on what happens if a calendar_id is invalid, an event creation fails, or an attendee email is malformed.
Parameter type specificity issues: Many parameters accept IDs but descriptions do not disambiguate ID types. Example: 'calendar_id' could mean internal Google ID or a natural name. Baseline: parameters should be suffixed with type (calendar_id, calendar_name). Pattern 'chat-data-model' requires accepting human-friendly identifiers. No evidence of name→ID resolution in the tool definitions.
Likely missing tool definitions or broken registration: Tools 'projects' and 'contacts' are located in 'cli/auth.py' and 'tools/contacts.py', but no actual tool registration code is visible (no @mcp_tool decorator or equivalent). Without seeing explicit tool_decorator or registration, these may not be properly exposed to the MCP server.