Loading ToolBench
A Next.js application providing voice-based calendar management with Google Calendar integration via Gemini Live API and MCP (Model Context Protocol)
Server defines 8 tools across two files (tools-mcp.ts and tools.ts) with complete JSON Schema input definitions and descriptions. However, critical issues reduce quality: (1) Duplicate tool sets (kebab-case MCP versions + snake_case HTTP versions) create maintenance burden and confusion; (2) Descriptions are verbose (300+ chars) with embedded examples and context handling instructions that should be in system prompts, not tool descriptions; (3) No output schemas documented, LLMs cannot predict response structure; (4) Missing error handling guidance; (5) calendarId parameter is optional with implicit default, violating the principle that defaults must not cause silent failures. Tools are well-named (verb_noun pattern) and parameters are typed, but lack the conciseness and clarity expected of production tools.
Create a new event in the user's Google Calendar. Use this when the user wants to schedule a meeting, set a reminder, or add any event to their calendar.
Create a new event in the user's Google Calendar. Use this when the user wants to schedule a meeting, set a reminder, or add any event to their calendar.
Delete an event from the user's Google Calendar. Use this when the user wants to cancel or remove an event.
Delete an event from the user's Google Calendar. Use this when the user wants to cancel or remove an event.
List upcoming events from the user's Google Calendar. Use this when the user wants to know their schedule, check what's coming up, or see their calendar.
Duplicate tool definitions across two files (kebab-case MCP tools in tools-mcp.ts and snake_case HTTP tools in tools.ts). This creates maintenance burden, version skew risk, and confusion about which set is canonical. Agents will see conflicting tool names for the same operations.
Descriptions are 300+ characters with embedded context handling instructions, examples, and multi-line guidance. Move context handling to system prompts; keep tool descriptions to 50-150 chars explaining WHAT and WHEN.
No output schemas documented. LLMs cannot predict response structure (e.g., what fields does list-events return? Is it an array of events or an object with 'items' and 'nextToken'?). This forces agents to guess and risks parsing errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
List upcoming events from the user's Google Calendar. Use this when the user wants to know their schedule, check what's coming up, or see their calendar.
Update an existing event in the user's Google Calendar. Use this when the user wants to reschedule, rename, modify, or add notes to an event. IMPORTANT CONTEXT HANDLING: - When user refers to "the event I just created", "the last event", "that event", or "the recent event", first use list-events with timeMin set to recent time (last hour) to find the event they're referring to. - You can update just ONE field (like description/notes) without providing all other fields - the API will automatically preserve existing values. - Examples: * "Add a note to the event I just created" → list recent events, find the latest one, then update only the description field * "Change the title of my 3pm meeting" → list events around 3pm, find the meeting, then update only the summary field * "Reschedule to 4pm" → list events to find which one, then update only start and end fields
Update an existing event in the user's Google Calendar. Use this when the user wants to reschedule, rename, modify, or add notes to an event. IMPORTANT CONTEXT HANDLING: - When user refers to "the event I just created", "the last event", "that event", or "the recent event", first use list_calendar_events with timeMin set to recent time (last hour) to find the event they're referring to. - You can update just ONE field (like description/notes) without providing all other fields - the API will automatically preserve existing values. - Examples: * "Add a note to the event I just created" → list recent events, find the latest one, then update only the description field * "Change the title of my 3pm meeting" → list events around 3pm, find the meeting, then update only the summary field * "Reschedule to 4pm" → list events to find which one, then update only start and end fields
calendarId parameter is optional with implicit default ('primary'). If a user intends to create an event in a specific calendar but omits calendarId, the event silently goes to 'primary' instead. Document the default explicitly and consider requiring it or providing a discovery tool.
No error handling guidance. Tools do not document what errors can occur (e.g., 'event not found', 'permission denied', 'invalid time range') or how agents should recover. Per pattern:recovery-guide, errors must tell the LLM what to do next.