Loading ToolBench
MCP server for Microsoft Outlook Calendar using COM Interop (Windows only)
This Outlook calendar MCP server has 6 well-named tools with complete input schemas and reasonable descriptions. However, there are several critical gaps: (1) output schemas are entirely undocumented, LLMs cannot infer what fields get_event, list_events, or search_events return, forcing them to guess downstream; (2) parameter descriptions lack format constraints and validation rules (e.g., ISO 8601 dates are mentioned but without length/pattern specs, eventId format unknown); (3) error handling is basic, no recovery guidance if event not found or validation fails; (4) no pagination on list_events despite calendar potentially returning hundreds of events; (5) parameter dependency rules undocumented (e.g., can startDate exist without endDate?). Tool naming is solid (verb_noun convention, clear distinctions). Descriptions are adequate (100-150 chars) but lack deployment/API specifics.
Create a new calendar event in Outlook
Delete a calendar event from Outlook
Get details of a specific calendar event by ID
List calendar events from Outlook. Optionally filter by date range (ISO 8601 format: YYYY-MM-DDTHH:mm:ss)
Search calendar events by query string (searches in subject and body)
Update an existing calendar event
Output schemas completely undocumented. LLMs cannot know what fields list_events, get_event, create_event, search_events return. This forces LLMs to guess field names and types for downstream calls, causing failures when field names differ from expectations (e.g., does create_event return 'id' or 'eventId'?). High token waste and error-prone chaining.
list_events has no pagination parameters (limit, offset, page) or result count. A calendar can have hundreds of events. Without pagination, the tool risks returning unbounded results that exhaust context windows. No statement of result limit in description.
Parameter constraints lack specificity. startDate and endDate descriptions say 'ISO 8601 format' but do not specify accepted patterns (YYYY-MM-DD vs YYYY-MM-DDTHH:mm:ss), timezone handling, or valid ranges. eventId format unknown, is it a GUID, hex string, or integer? Without format constraints, LLMs generate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Error handling minimal. If eventId not found, create_event fails with missing required fields, or date validation fails, the server likely returns generic errors without actionable recovery hints. No guidance on 'try search_events first' or 'check date format'. This blocks agent self-correction.
No parameter dependency documentation. Can startDate be passed without endDate? What happens if endDate < startDate? Are attendees in outlook_create_event validated against a directory? Undocumented dependencies force LLMs to guess and cause silent misuse.
delete_event and update_event are stateful/destructive but lack confirmation or dry-run support. No warning in description. Agents may accidentally delete or overwrite events without explicit user consent. Pattern suggests confirmation flow for irreversible ops.