Loading ToolBench
An MCP server for Microsoft Outlook email management, enabling AI models to read, search, send, and manage emails through the Microsoft Graph API
This Outlook MCP server provides 17 tools with mostly complete schemas and descriptions. Naming conventions are clear and verb-forward (ListEmails, SendEmail, etc.). All tools have descriptions and input schemas with type definitions. However, there are notable gaps: (1) output schemas are not explicitly documented, the code shows test mocks but no formal response structure declarations visible in tool definitions; (2) parameter descriptions are present but often minimal (e.g., 'folder_id' described as 'Folder ID (optional, defaults to inbox)', no hint on format or examples); (3) error handling is basic, no guidance on recovery steps or categorization of retryable vs fatal errors; (4) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having tools that read, write, and delete; (5) some tools combine related operations (ReplyToEmail + ReplyAllToEmail) that could benefit from a single parameterized tool. The test suite shows well-structured mocks and response formatting, but the actual tool registration code (not visible in full) appears to lack formal schema export. Average per-tool score: 62.
Copy an email to a different mail folder
Create a new email draft in the Drafts folder
Create a new mail folder in the user's Outlook mailbox
Delete an email (moves to Deleted Items)
Forward an email to one or more recipients
Get details and content of a specific email attachment
List attachments on an email message
Output schemas not explicitly documented in tool definitions. Tests show response structure (id, subject, from, etc.) but no formal response type declarations visible. LLMs cannot infer downstream field names needed for tool chaining.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). DeleteEmail, SendEmail, and other state-mutating tools lack explicit classification. LLMs cannot determine which tools are safe to retry without guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
List recent emails from the inbox or a specified folder
List mail folders in the user's mailbox
Mark an email as read or unread
Move one or more emails to a different mail folder
Read the full content of a specific email message
Reply to all recipients of an email message
Reply to an email message (reply to sender only)
Search emails by subject, body, or sender
Send a previously created email draft
Send an email message to one or more recipients
Error handling lacks recovery guidance. No tool descriptions indicate what to do on failure (retry? ask user? abort?). Example: SearchEmails returns empty list but does not guide LLM on whether to refine query or try different search.
Parameter descriptions are minimal. 'folder_id' described as 'Folder ID (optional, defaults to inbox)', no format specification, no hint on how to obtain valid IDs. LLMs cannot determine if they should pass folder names vs system IDs.
ReplyToEmail and ReplyAllToEmail are nearly identical tools differing only in behavior. Should consolidate into single Reply tool with 'reply_all: boolean' parameter to reduce LLM confusion and decision overhead.
No dry-run or confirmation step for destructive operations (DeleteEmail, MoveEmails). Agents cannot preview what will be deleted before executing. Missing pattern:confirmation-request.