Loading ToolBench
A Model Context Protocol server that bridges Microsoft Outlook and Microsoft Graph API, enabling AI agents to read emails, manage calendars, and search contacts through the MCP protocol.
Server defines 5 tools with basic schemas and descriptions, but exhibits moderate gaps in parameter documentation, output schema specification, and error handling. Tool naming follows verb_noun convention and is clear. Descriptions are present but brief (10-34 chars for most tools, below the 50-200 char production baseline). Input schemas are visible and mostly complete with required field declarations, but lack output schemas and detailed parameter constraints. No error recovery guidance or per-tool error classification. Security concern: session tokens are stored in memory and passed via global state rather than being injected server-side at tool execution time.
Create a new calendar event
Get the full content of a specific email
List calendar events for a given time range
List recent emails from the inbox
Send a new email
Output schemas completely undocumented. LLMs cannot determine what fields to expect from tool responses (e.g., what does list_messages return? Message IDs? Timestamps? Sender details?). Breaks downstream tool chaining and forces agents to guess at response structure.
Parameter descriptions are minimal or absent context. 'top' in list_messages lacks explanation of default behavior or limits; 'start'/'end' in list_events do not specify ISO 8601 format details, timezone handling, or whether open/closed intervals are inclusive; 'location' in create_event is optional but no guidance on what happens if omitted.
No documented pagination or result limiting. list_messages and list_events may return unbounded results, risking context window exhaustion. No limit parameter, offset/cursor mechanism, or documentation of maximum result count. Production tools require pagination (pattern:paginated-result).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
No error handling or recovery guidance. Tool handler does not validate inputs (e.g., is 'to' in send_message a valid email?), does not classify errors as retryable vs user-fixable, and does not return actionable error messages. An LLM receiving a raw error has no guidance on next steps.
Security: OAuth tokens stored in global state and session memory. Code shows '(global as any).lastAccessToken = tokens.access_token' and session-based token storage without encryption at rest. Tokens can leak via server restarts, session persistence, or memory dumps. Best practice: use server-side secret injection and vault.
Tool handler registration incomplete. CallToolRequestSchema handler is defined but the implementation is cut off in the provided code ('This is tricky because the request handler doesn't have access to the Express request object directly. In a real...'). Cannot verify tool execution logic, input validation, or how Microsoft Graph API responses are mapped to tool outputs.
Destructive operations (send_message, create_event) lack confirmation or dry-run support. No pattern:confirmation-request or pattern:idempotent-operation. Agent could accidentally send duplicate emails or create duplicate events on retry without safeguards.