MCP server that connects Claude to an ON-PREMISE Microsoft Exchange Server calendar (2013/2016/2019) via the EWS (Exchange Web Services) endpoint. Authentication: NTLM (Windows domain). Read-only by default, with optional create/update/delete of calendar items when explicitly enabled.
Exchange Calendar MCP has clear, action-oriented tool names (list_appointments, create_appointment, delete_appointment) and reasonable descriptions (avg ~120 chars). All 7 tools have input schemas with type definitions and parameter descriptions. However, output schemas are undocumented (tools return plain strings, not structured objects), error handling lacks recovery guidance, and parameter constraints are described in text rather than enforced via enums or JSON Schema patterns. The server is read-only by default with optional write tools, which is good security practice, but destructive operations (delete_appointment) lack confirmation/dry-run patterns. Parameter descriptions are adequate but could be more prescriptive about formats and constraints.
Create a new calendar appointment. start / end in 'YYYY-MM-DD HH:MM' format. attendees = comma-separated emails (an invitation email is sent to the attendees, if any).
Delete a calendar appointment. The item is moved to Deleted Items (recoverable) and cancellations are sent to attendees.
List calendar appointments between two dates (inclusive). start_date / end_date in YYYY-MM-DD format (or 'today'/'tomorrow'). If end_date is empty, the same day as start_date is used.
Show appointments for the next N days (default 7, max 366).
Check that the credentials and the EWS endpoint work.
Show today's appointments.
Output schemas undocumented. All tools return plain strings; LLMs cannot parse structured results or chain downstream calls. No documented field names, types, or pagination.
Destructive operation (delete_appointment) lacks confirmation or dry-run pattern. Agents can permanently delete calendar items without a safety gate.
Parameter constraints described in text, not enforced via JSON Schema. 'days' parameter says 'max 366' but no maxValue constraint; 'start'/'end' datetime format is described but no regex pattern enforces it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Update an existing calendar appointment. Only non-empty fields are updated.
Error handling returns raw exceptions without recovery guidance. No actionable error messages to guide LLM retry or fallback strategies.
Large result sets (list_appointments over 366 days) not paginated. No limit parameter or next_cursor. Returning all items in one string response wastes tokens and risks context exhaustion.