Loading ToolBench
A Model Context Protocol server for Google Workspace (Gmail and Google Calendar)
Server has 9 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with type definitions. However, descriptions lack actionable context for LLM selection, parameter descriptions are minimal, and output schemas are not documented. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Error handling is generic (500 errors with error.message). Naming follows verb_noun convention well (list_emails, send_email, delete_event). No security concerns visible in parameter design (no secrets exposed). Composition is reasonable, tools are single-purpose, but chaining metadata (IDs needed for follow-up calls) is not explicitly documented in responses.
Create a new calendar event
Delete a calendar event
Get email attachment data
List recent emails from Gmail inbox
List upcoming calendar events
Modify email labels (archive, trash, mark read/unread)
Search emails with advanced query
Descriptions are too short (10-50 chars) and lack actionable context. 'List recent emails from Gmail inbox' does not explain when to use list_emails vs search_emails, what fields are returned, or prerequisites. LLMs cannot reliably select the right tool.
Output schemas are not documented. Callers cannot know what fields to expect (e.g., does list_emails return email_id, message_id, or id?). This forces LLMs to guess field names for downstream tool calls, increasing errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Send a new email
Update an existing calendar event
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. send_email, modify_email, create_event, update_event, delete_event are WRITE/DESTRUCTIVE but lack annotations. Agents cannot distinguish safe from risky tools.
Parameter descriptions are minimal or missing. 'query' in search_emails says 'Gmail search query (e.g., "from:[email protected] has:attachment")' but does not explain valid syntax, length limits, or error cases. LLMs cannot validate input before calling.
Error handling is generic. HTTP 500 responses return only error.message with no guidance on retry, user action, or root cause. 'Error downloading attachment: ...' tells the LLM nothing about whether to retry, ask the user, or give up.