Loading ToolBench
Yahoo Mail MCP Server - Full email management via IMAP with OAuth2 authentication
The Yahoo Mail MCP Server presents a well-structured toolset with clear, actionable descriptions and properly typed input schemas. All 6 tools are explicitly registered with descriptions and input schemas visible in server.js. However, several patterns are missing: output schemas are not documented, error handling guidance is not specified, tool annotations (readOnlyHint/destructiveHint) are absent, and parameter constraints could be stricter. The server demonstrates good naming conventions (verb_noun pattern) and reasonable parameter descriptions, but falls short of production-grade documentation. Average per-tool score: 68/100.
Move emails to Archive folder using UIDs for long-term storage. UIDs are permanent identifiers.
Move emails to Trash folder using UIDs (soft delete, recoverable). UIDs are permanent identifiers.
List recent emails from a Yahoo Mail folder. Returns UIDs (permanent identifiers) and enriched metadata including size, flags, and attachment status.
Mark emails as read using UIDs. UIDs are permanent identifiers.
Read email content using UIDs (permanent identifiers). UIDs don't change when emails are deleted. Get UIDs from list_emails or search_emails.
Search emails using UIDs with advanced filters. Returns UIDs which are permanent identifiers that don't change when emails are deleted. Get UIDs from results for subsequent operations.
Output schemas are completely undocumented across all 6 tools. LLMs cannot determine what fields to expect from responses, blocking downstream tool chaining and forcing re-discovery calls.
Tool annotations missing entirely: no readOnlyHint on read-only tools (list_emails, read_email, search_emails), no destructiveHint on modify/delete tools (delete_emails, archive_emails), no idempotentHint on idempotent tools (mark_as_read). Agents cannot infer retry safety or state-changing consequences.
No error handling guidance. Tools lack documentation of what errors can occur, whether they're retryable, and what recovery steps the LLM should take. E.g., 'If UIDs are invalid, list_emails to get fresh UIDs' or 'If folder doesn't exist, call list_folders.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 75 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Irreversible operations (delete_emails, archive_emails) lack confirmation/dry-run pattern. Agents can't preview what will be deleted or request user confirmation before permanently moving emails. No dry-run parameter or separate confirm_delete tool.
Parameter constraints are underspecified. 'count' and 'offset' lack min/max bounds, dateFrom/dateTo lack explicit format strings in schema, 'sender' and 'query' could benefit from length/pattern constraints to prevent malformed IMAP queries.
No list_folders or list_labels discovery tool visible. Descriptions reference 'Use list_folders to see available folders' but this tool is not implemented, forcing agents to guess folder names or hardcode assumptions (INBOX, Archive).
Bulk operation response design not documented. When delete_emails or archive_emails process multiple UIDs, do they return per-item success/failure or an all-or-nothing result? If one UID fails, what happens to the others? This blocks agent error recovery.