Loading ToolBench
AI-powered email MCP server with Gmail/Outlook connectors. Provides tools for email search, thread operations, labels, rules-as-code automation, AI-powered drafting, semantic search, inbox triage, and analytics.
IntentMail exhibits significant structural issues that impact agent usability. While it provides 45 tools with a variety of email operations, most lack sufficient depth in descriptions and parameter documentation. Critically, input schemas are present but many parameter descriptions are generic ('Email ID', 'Email account'). The server targets email automation but lacks the specificity required for reliable LLM-driven tool selection. No tool annotations (readOnlyHint, destructiveHint) are visible despite a diverse risk profile ranging from READ_ONLY to DESTRUCTIVE operations. Error handling and recovery guidance are not evident in the tool definitions. The composition is broad but shallow, many tools are tightly coupled to specific providers (Gmail, Outlook) without clear fallback or abstraction.
Health check tool for MCP server status
Perform quick actions on emails
Run custom analytics queries on email data
Get email analytics summary
Apply a label to an email or thread
Apply a rule to emails
Get attachment statistics
Complete OAuth authentication and save credentials
Parameter descriptions are generic and lack actionable constraints. 'Email account', 'Email ID', 'Rule ID' repeat across many tools without explaining format, valid range, or how to obtain the value. LLMs cannot infer whether to pass 'john@example.com', 'user_123', or a system UUID.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint) despite a clear risk profile spanning READ_ONLY, WRITE, IRREVERSIBLE, and DESTRUCTIVE operations. Without these annotations, agents cannot reason about side effects or retry safety. mail_stage_delete→mail_commit_deletions is a destructive two-step pattern that LLMs may misapply.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | 1.25.2+ | v1 |
Start OAuth authentication flow for a new email account
Commit staged email deletions
AI-powered compose suggestions
Create a new email automation rule
Generate a daily email digest summary
Delete an email automation rule
Get deletion audit log
AI-powered email draft generation
Export email data as Parquet file
Extract and process attachments from emails
Find duplicate emails
Flag or unflag an email
Download an email attachment
Get audit log of rule applications
Retrieve a complete email thread
List all configured email accounts
List attachments in an email
List conversation contexts for emails
List all folders in an email account
List all labels in an email account
List all email automation rules
List emails staged for deletion
Move an email to a folder or label
Parse and analyze email search queries
Rollback rule applications
Search emails with Gmail-style query syntax
AI-powered semantic email search
Send an email
Stage emails for deletion
AI-powered email summarization
Sync emails from a connected account
Get synchronization statistics
AI-powered inbox triage and priority assignment
Remove emails from deletion staging
Start watching for new emails with push notifications
Get status of email watch
Stop watching for new emails
No error handling or recovery guidance visible in tool descriptions. mail_auth_start and mail_auth_complete do not document OAuth timeout, provider-specific error codes, or recovery paths. mail_commit_deletions lacks a dry-run mode or confirmation step; agents risk irreversible data loss.
mail_analytics_query accepts raw SQL (DuckDB) as a parameter. This is a SQL injection risk and violates the secret-injection pattern. Query templates or a constrained query builder should replace free-form SQL.
mail_auth_start and mail_auth_complete expose OAuth flows as tool parameters, raising security concerns. Credentials and OAuth tokens must never appear in tool parameters; they should be handled server-side with environment injection.
mail_create_rule documents 'conditions' and 'actions' as bare arrays without specifying structure, valid schemas, or example payloads. LLMs cannot construct valid rule definitions without explicit schema documentation.
mail_action uses a generic 'action' parameter with enum values listed in description ('archive, delete, mark_unread, mark_read, snooze') rather than as a constrained enum in the schema. This invites hallucinated action names.
No pagination documentation for list_* tools (mail_list_labels, mail_list_rules, mail_list_folders, mail_list_attachments). Large result sets could exhaust context windows; limit and offset/cursor parameters are missing.
Tool descriptions are often under 50 characters and lack WHEN context. E.g., mail_sync: 'Sync emails from a connected account' does not explain whether this is incremental/full, how often to call it, or when it conflicts with mail_watch_start. Agents cannot determine appropriate usage.
No output schema documentation visible. Tools like mail_search, mail_semantic_search, mail_list_rules, mail_analytics_query return results but agent cannot predict field names, types, or structure. This forces agents to reason about outputs without guidance.
Destructive two-step pattern (mail_stage_delete + mail_commit_deletions) lacks confirmation or dry-run. No tool to preview staged deletions before commit. Agent could stage and commit without review.
mail_send, mail_draft, and mail_compose_suggest are related but lack clear composition guidance. No documented preference: should agent call mail_draft then mail_send? Or compose_suggest first? Ambiguous tool relationships waste reasoning tokens.