Loading ToolBench
Office 365 MCP Server for Claude Code - Secure Microsoft Graph API integration with 45 tools
This server exhibits major definition quality issues across nearly all dimensions. While tools are named reasonably well with verb-noun patterns (get_, search_, send_, list_), the critical failures lie in parameter descriptions, output schemas, and error handling. Only 1 of 10 tools has complete input schemas with parameter descriptions. Most tools lack documented return types entirely. Parameter descriptions are minimal or absent (e.g., 'The ID of the email to retrieve details for' is generic; no guidance on format or constraints). No tool includes output schema documentation. Error handling is absent, no recovery guidance, no categorization of error types. Security concerns: credentials are validated as environment variables (good), but the server validates them at startup rather than per-request (less flexible for distributed deployments). The rubric baseline shows 100% of A+ tools have documented return types and 94% have complete docstrings, this server has neither.
Download an attachment from an email (max 10MB)
Get calendar events for the next N days
Get list of attachments for a specific email
Get detailed information about a specific email including headers, body, attachments metadata
Get emails from a specific mail folder
Get recent emails from Office 365
Missing input schema for list_mail_folders. No properties defined, no parameter descriptions. Cannot assess parameter constraints or expected input format.
No output/return schemas documented for any tool. LLMs cannot plan downstream calls or extract needed fields. Baseline: 100% of A+ tools have documented return types.
Parameter descriptions are generic or missing context. Example: 'The ID of the email to retrieve details for' does not explain format (UUID, message ID from Graph API, etc.), whether it is required, or constraints. Rubric baseline: parameter descriptions average 72 chars and explain format, range, and allowed values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
List all mail folders for the user
Search emails with optional query parameter and result limit
Send an email to a recipient
Send an email with file attachments
No error handling guidance. Tools lack recovery instructions, error categorization, or actionable error messages. Baseline: error responses should tell LLM what to do next (retry, ask user, or fail).
No confirmation or dry-run support for destructive operations. send_email and send_email_with_attachments are irreversible (Risk: WRITE) but lack confirmation patterns. Agents need safeguards against accidental sends.
Tool name 'send_email_with_attachments' signals multiple responsibilities. Should be clarified: is this a separate tool from send_email, or should attachments be an optional parameter in a unified send_email? Baseline: tool names should have one clear responsibility; 'and' in names signals split needed.
search_emails and get_recent_emails both retrieve emails but with different mechanisms. Naming is distinct, but descriptions do not clarify when to use search_emails vs get_recent_emails vs get_folder_emails. LLM reasoning waste.
No pagination guidance for result-returning tools. search_emails accepts maxResults (max 1000) but get_recent_emails has a count default of 10 with no maximum. Inconsistent constraints. No mention of cursors, offsets, or result limits to prevent context window exhaustion.
Tool descriptions lack WHEN to use guidance. E.g., 'Get recent emails from Office 365' does not explain whether to use this vs search_emails vs get_folder_emails. No dependency hints (e.g., 'Call list_mail_folders first to discover folder IDs').
download_attachment advertises '(max 10MB)' constraint in description but no parameter-level size validation or error handling documented. What happens if attachment exceeds 10MB? Does download_attachment return an error, or silently fail?