Loading ToolBench
An MCP server for Gmail integration with email drafting capabilities, prompts, and contact directory resources
Single tool with adequate schema but weak descriptions and no error guidance. Tool name 'write_email_draft' is clear and verb-first, following naming conventions. Input schema is present with typed parameters (string) and descriptions. However, the tool description is verbose (400+ chars) and includes implementation details (HttpError, environment variables) that belong in error handling, not the main description. No output schema is documented, LLMs cannot predict the structure of the returned dict. Error handling is minimal: HttpError is caught but the response is just 'None', with no guidance on what went wrong or how to recover. The tool modifies state (creates Gmail draft) but lacks idempotent or confirmation patterns. No tool annotations (destructiveHint, idempotentHint) are present.
Create a draft email using the Gmail API. Args: recipient_email (str): The email address of the recipient. subject (str): The subject line of the email. body (str): The main content/body of the email. Returns: dict or None: A dictionary containing the draft information including 'id' and 'message' if successful, None if an error occurs. Raises: HttpError: If there is an error communicating with the Gmail API. Note: This function requires: - Gmail API credentials to be properly configured - USER_EMAIL environment variable to be set with the sender's email address - Appropriate Gmail API permissions for creating drafts
No output schema documented. Tool returns dict with 'id' and 'message' fields, but LLMs cannot predict structure or plan downstream calls. Baseline: 100% of A+ tools document return types.
Error handling returns None with no guidance. When HttpError occurs, LLM receives None and has no context on what failed or how to recover. Should return structured error with actionable message.
Tool description mixes implementation details (HttpError, environment variables, Gmail API permissions) with functional description. Should be 50-200 chars focusing on WHAT and WHEN, not HOW.
Destructive operation (creates Gmail draft) lacks tool annotations. Should include destructiveHint=true and idempotentHint=false to signal to agents that this modifies state and may have side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
No confirmation or dry-run pattern for irreversible operation. Agents may accidentally create drafts; should support a preview or confirmation step before committing.