What can you do with this server?

The EWS Meeting MCP server provides a secure, auditable, human-in-the-loop interface for scheduling and managing Outlook meetings on on-premises Exchange via EWS. All write operations require human confirmation. Setup & Credential Checks * ews_setup_check — Verify full EWS configuration readiness * ews_keychain_status — Check if EWS password is available from environment or macOS Keychain * ews_probe — Test that the configured account can connect to Exchange Read Calendar & Availability * ews_list_calendar — List upcoming calendar events * ews_find_calendar_events — Search events by time window, subject, location, organizer, or attendee; returns exact EWS IDs and changekeys * ews_get_free_busy — Retrieve free/busy blocks for one or more attendees Attendee & Room Discovery * ews_resolve_attendees — Resolve names or aliases against the Exchange directory * ews_list_rooms — List available meeting rooms with optional capacity and text filters Slot Suggestion * ews_suggest_slots — Find overlapping free slots for attendees and rooms, respecting workday hours and avoid windows Create Meetings (Preview → Confirm) * ews_create_meeting_preview — Preview a meeting invite without sending anything * ews_create_meeting_confirmed — Create the meeting and send invitations after providing confirm=true and a matching confirmation_id Update Meetings (Preview → Confirm) * ews_update_meeting_preview — Preview changes to an existing meeting without saving * ews_update_meeting_confirmed — Apply updates after confirming with a confirmation_id Cancel Meetings (Preview → Confirm) * ews_cancel_meeting_preview — Preview cancellation without deleting or notifying anyone * ews_cancel_meeting_confirmed — Cancel the meeting and optionally send cancellation notices after confirmation Verification & Auditing * ews_verify_meeting — Verify a calendar item's current server-side state by EWS id/changekey * ews_get_audit_log — Read the local audit log of all lifecycle actions (preview, confirmed, duplicate, in-progress, error)

EWS Meeting MCP

by ap311036

Overview Schema Related Servers Score Discussions

Python

Local

The EWS Meeting MCP server provides a secure, auditable, human-in-the-loop interface for scheduling and managing Outlook meetings on on-premises Exchange via EWS. All write operations require human confirmation.

Setup & Credential Checks

ews_setup_check — Verify full EWS configuration readiness
ews_keychain_status — Check if EWS password is available from environment or macOS Keychain
ews_probe — Test that the configured account can connect to Exchange

Read Calendar & Availability

ews_list_calendar — List upcoming calendar events
ews_find_calendar_events — Search events by time window, subject, location, organizer, or attendee; returns exact EWS IDs and changekeys
ews_get_free_busy — Retrieve free/busy blocks for one or more attendees

Attendee & Room Discovery

ews_resolve_attendees — Resolve names or aliases against the Exchange directory
ews_list_rooms — List available meeting rooms with optional capacity and text filters

Slot Suggestion

ews_suggest_slots — Find overlapping free slots for attendees and rooms, respecting workday hours and avoid windows

Create Meetings (Preview → Confirm)

ews_create_meeting_preview — Preview a meeting invite without sending anything
ews_create_meeting_confirmed — Create the meeting and send invitations after providing confirm=true and a matching confirmation_id

Update Meetings (Preview → Confirm)

ews_update_meeting_preview — Preview changes to an existing meeting without saving
ews_update_meeting_confirmed — Apply updates after confirming with a confirmation_id

Cancel Meetings (Preview → Confirm)

ews_cancel_meeting_preview — Preview cancellation without deleting or notifying anyone
ews_cancel_meeting_confirmed — Cancel the meeting and optionally send cancellation notices after confirmation

Verification & Auditing

ews_verify_meeting — Verify a calendar item's current server-side state by EWS id/changekey
ews_get_audit_log — Read the local audit log of all lifecycle actions (preview, confirmed, duplicate, in-progress, error)

EWS Meeting MCP

npm License: MIT Node.js >=18 Python

The MCP server for safely reading Outlook inbox messages, sending self-only reports, and scheduling meetings on on-prem Exchange EWS.

EWS Meeting MCP gives coding assistants and desktop agents a safe, structured way to read Outlook inbox messages and availability, send a report only to the configured mailbox, discover rooms, suggest meeting slots, and create, update, or cancel meetings only after an explicit human confirmation step.

It is built for companies where calendar access is sensitive infrastructure: regulated teams, internal networks, strict security review, legacy Exchange deployments, and organizations that cannot simply hand a cloud agent broad Microsoft 365 permissions. Credentials stay local, meeting writes are previewed before they touch Exchange, self-only report sends require idempotency protection, and every write can be traced through a local audit trail.

npx ews-meeting-mcp

Why This Exists

Many teams still run calendar infrastructure through on-prem Exchange/EWS. General-purpose agents can reason about scheduling, but they should not receive raw passwords, guess attendee addresses, or send calendar invitations without a reviewable checkpoint.

This is not a generic Outlook wrapper or a Microsoft Graph-first calendar connector. It is designed for the stricter enterprise case: local EWS access, room resources, explicit human approval, duplicate-send protection, and audit-friendly meeting lifecycle tools.

This project wraps Exchange calendar operations in a small MCP surface with:

Room-aware scheduling: finds overlapping attendee availability and filters meeting rooms by Exchange discovery or local policy.
Human-in-the-loop writes: create, update, and cancel operations require a preview plus a matching confirmation_id.
Local-first credential handling: reads .env, shell environment, or macOS Keychain without passing passwords through the model.
Structured recovery: setup failures return machine-readable error codes and user-facing setup commands.
Auditability: lifecycle previews, confirmed actions, duplicate confirmations, in-progress states, and structured errors are written to a local JSONL audit log.
Agent-ready instructions: the MCP server exposes tool descriptions and initialization guidance, and the repo includes a companion skill for agents that support skills.

Related MCP server: MCP Outlook Scheduler

What Agents Can Do

Capability	Tooling	Safety posture
Check setup and credentials	`ews_setup_check`, `ews_keychain_status`	Never returns the EWS password
Set up meeting signatures	`ews_signature_setup_guide`	Returns copyable HTML sample and local env guidance
Read Outlook inbox	`ews_search_emails`, `ews_read_email`	Read-only; does not mark messages as read or change mailbox state
Send a weekly report to self	`ews_send_email_to_self`	Only sends to `EWS_EMAIL`; recipient is not an input; requires a stable idempotency key and real EWS CreateItem + SendItem
Read calendar availability	`ews_list_calendar`, `ews_get_free_busy`, `ews_find_calendar_events`	Read-only
Resolve people and rooms	`ews_resolve_attendees`, `ews_list_rooms`	Uses Exchange directory when available
Suggest slots	`ews_suggest_slots`	Applies local workday, avoid windows, and room capacity
Create meetings	`ews_create_meeting_preview`, `ews_create_meeting_confirmed`	Supports optional weekly recurrence; requires preview, explicit approval, and matching confirmation id
Update meetings	`ews_update_meeting_preview`, `ews_update_meeting_confirmed`	Requires exact EWS item metadata and matching confirmation id
Cancel meetings	`ews_cancel_meeting_preview`, `ews_cancel_meeting_confirmed`	Requires exact EWS item metadata and matching confirmation id
Verify and audit	`ews_verify_meeting`, `ews_get_audit_log`	Confirms server-side state without exposing credentials

Documentation

Usage Guide: local setup, Keychain, scheduling policy, smoke checks, CLI examples, MCP config, and npm wrapper details.
Agent Guide: tool contracts, setup checks, attendee resolution, room selection, preview-confirm flows, audit log, and verification rules.
Publishing: npm package and GitHub Actions release checklist.

Quick Start

1. Configure EWS

Create a .env file in the working directory or provide equivalent environment variables:

EWS_ENDPOINT=https://mail.company.com/EWS/Exchange.asmx
EWS_EMAIL=your_user@company.com
EWS_USERNAME='DOMAIN\your_user'
EWS_AUTH_TYPE=NTLM
EWS_TIMEZONE=Asia/Taipei

Use EWS_AUTH_TYPE=BASIC only if IT confirms Basic auth is enabled and the endpoint is protected by HTTPS.

2. Store the Password

For local development, the generic ACCOUNT_PASSWORD override works, but do not put it in MCP config:

ACCOUNT_PASSWORD='your-password'

On macOS, Keychain is safer than storing the password in .env or MCP client config:

read -rsp "Account password: " ACCOUNT_PASSWORD
echo
security add-generic-password -U -s ews-meeting-mcp-account-password -a 'DOMAIN\your_user' -w "$ACCOUNT_PASSWORD"
unset ACCOUNT_PASSWORD

Use the same Keychain service/account pair from any local tool that needs this account password:

ACCOUNT_PASSWORD_KEYCHAIN_SERVICE=ews-meeting-mcp-account-password
ACCOUNT_PASSWORD_KEYCHAIN_ACCOUNT='DOMAIN\your_user'

If ACCOUNT_PASSWORD_KEYCHAIN_ACCOUNT is omitted, EWS_USERNAME is used. ACCOUNT_PASSWORD is only a generic local override; Keychain is preferred.

3. Add the MCP Server

For an npm-installed MCP client:

{
  "mcpServers": {
    "ews-meeting-mcp": {
      "command": "npx",
      "args": ["-y", "ews-meeting-mcp@0.1.25"],
      "env": {
        "EWS_ENDPOINT": "https://mail.company.com/EWS/Exchange.asmx",
        "EWS_EMAIL": "your_user@company.com",
        "EWS_USERNAME": "DOMAIN\\your_user",
        "ACCOUNT_PASSWORD_KEYCHAIN_SERVICE": "ews-meeting-mcp-account-password",
        "ACCOUNT_PASSWORD_KEYCHAIN_ACCOUNT": "DOMAIN\\your_user",
        "EWS_AUTH_TYPE": "NTLM",
        "EWS_TIMEZONE": "Asia/Taipei"
      }
    }
  }
}

For a local checkout:

{
  "mcpServers": {
    "ews-meeting-mcp": {
      "command": "/path/to/ews-meeting-mcp/.venv/bin/python",
      "args": ["-m", "ews_meeting_mcp.mcp_server"],
      "cwd": "/path/to/ews-meeting-mcp",
      "env": {
        "PYTHONPATH": "src"
      }
    }
  }
}

Optional: Add an Outlook-Style Signature

Meeting invites append a configured HTML signature by default. Ask the MCP tool for a copyable starter template:

ews_signature_setup_guide

Save the returned sample_html as ews-meeting-signature.html in the MCP working directory, then edit the name, email, title, logo URL, and disclaimer. You can also point to a different file:

EWS_MEETING_SIGNATURE_HTML_PATH=/path/to/ews-meeting-signature.html
EWS_MEETING_SIGNATURE_ENABLED=true

Use an HTTPS logo URL recipients can access, or replace the <img> source with a base64 data URI. Set EWS_MEETING_SIGNATURE_ENABLED=false to temporarily stop appending the signature.

4. Verify Setup

npx ews-meeting-mcp --cli env
npx ews-meeting-mcp --cli probe

The first command prints the configured endpoint and account without printing the password. The second command validates that the account can connect to EWS.

Agent Workflow

For incoming Outlook mail, search the configured inbox first and then read the selected message:

user asks about company email
-> ews_setup_check
-> ews_search_emails with the narrowest known filters
-> user selects or identifies one message
-> ews_read_email with the exact id and optional changekey

These mailbox tools are read-only. They do not mark messages as read, send mail, move messages, or change labels.

For the Thursday Jira weekly-report automation, compose the report from the Jira results and then call the dedicated self-only mail tool through this EWS MCP:

weekly report is ready
-> ews_setup_check
-> ews_send_email_to_self with subject, body, and a stable idempotency_key
-> stop after sent=true; do not use Gmail, to: me, or another mail provider

ews_send_email_to_self takes no recipient, to, cc, or bcc argument. It obtains the only recipient from EWS_EMAIL, sends through Exchange EWS, and appends the configured HTML signature by default. It does not write the email body or recipient address to the audit log. Reuse the same idempotency key for an automation retry; a completed or in-progress key will not call Exchange again.

Scheduling should follow this shape:

user request
-> ews_setup_check
-> ews_signature_setup_guide, if the user needs help creating the optional HTML signature
-> ews_resolve_attendees, if names or aliases are provided
-> ews_list_rooms, if a room may be needed
-> ews_suggest_slots
-> user chooses a slot and room
-> ews_create_meeting_preview
-> show exact invite details, recurrence if present, and confirmation_id
-> user explicitly confirms
-> ews_create_meeting_confirmed with confirm=true and the same confirmation_id
-> ews_verify_meeting, when item id and changekey are available

Recurring meetings are created by passing a structured recurrence object to both preview and confirmed create calls. For example, "every Monday and Wednesday" uses weekly recurrence:

{
  "type": "weekly",
  "interval": 1,
  "weekdays": ["MO", "WE"],
  "range": {
    "type": "numbered",
    "count": 10
  }
}

"Every business day until 7/26" means Monday through Friday, without holiday or makeup-day handling:

{
  "type": "weekly",
  "interval": 1,
  "weekdays": ["MO", "TU", "WE", "TH", "FR"],
  "range": {
    "type": "end_date",
    "end_date": "2026-07-26"
  }
}

If the user asks only for weekdays such as "every Monday and Wednesday" without an end date, occurrence count, or explicit no-end choice, ask for one before previewing.

Existing meeting changes should use exact calendar metadata:

user asks to update or cancel a meeting
-> ews_find_calendar_events with the narrowest known time window
-> user chooses one exact event, if more than one candidate exists
-> ews_update_meeting_preview or ews_cancel_meeting_preview
-> show current/proposed details, warnings, and confirmation_id
-> user explicitly confirms
-> matching confirmed tool with confirm=true and the same confirmation_id

Agents should never infer an event from subject text when multiple candidates are possible.

Safety Model

EWS Meeting MCP is designed around a simple rule: reads may be automated, and every write must have a narrow safety gate. Inbox reads are limited to explicit read-only search and read tools; meeting writes require preview plus explicit confirmation, while the self-only report send requires configured-self enforcement plus idempotency protection.

Authentication failures are fail-fast: the EWS client uses FailFast, and after one invalid-credential or locked-account response the MCP blocks all later EWS calls in that process. Fix the shared Keychain item and restart the MCP before trying again.
Confirmed create, update, and cancel tools refuse to run unless confirm=true is passed.
Confirmed tools require the exact confirmation_id returned by the matching preview.
Confirmed update and cancel tools also require the exact EWS id and changekey from ews_find_calendar_events or a prior verified result.
Duplicate confirmed requests return error_code: "duplicate_confirmation" with prior result metadata instead of calling EWS again.
In-progress confirmations return error_code: "confirmation_in_progress" and should not be blindly retried.
Preview tools never save, move, delete, or send Exchange notifications.
ews_send_email_to_self is the only mail-write capability. It is self-only, requires EWS_EMAIL to be configured, and sends a saved draft with EWS CreateItem followed by SendItem; it does not accept an arbitrary recipient.
Self-only sends require a stable, non-secret idempotency_key. A duplicate or in-progress key is refused before another EWS send. If delivery is uncertain, inspect Sent Items before retrying.
Self-only send audit entries contain only action/status and non-sensitive delivery/idempotency metadata; they do not contain the configured email address, subject, body, password, or token.
The local confirmation ledger and audit log store operation metadata, not EWS passwords.

If ews_setup_check returns ready: false, an agent should show the returned user_message or setup_command verbatim and stop. It should not ask for attendee emails or continue scheduling as a workaround.

Scheduling Policy

By default, scheduling tools look for ews-meeting-policy.json in the current working directory. Set EWS_MEETING_POLICY_FILE to point at a different file.

If no policy file exists, built-in defaults are used:

workday: 10:00 to 18:00
avoid: 12:00-14:00
fallback rooms: 2-11, 2-13, 2-14, 3-1, 3-2, 3-4

Live room selection uses Exchange room-list discovery when available, then falls back to configured rooms.

Example policy:

{
  "workday_start": "10:00",
  "workday_end": "18:00",
  "avoid": ["12:00-14:00"],
  "rooms": [
    {
      "alias": "3-1",
      "name": "3-1 Meeting Room(12P)",
      "email": "3-1MeetingRoom@company.com",
      "capacity": 12
    }
  ]
}

Policy rooms are merged with the default fallback rooms by alias. A matching alias overrides the default room, and new aliases are appended.

CLI Usage

The npm wrapper starts the MCP server by default:

npx ews-meeting-mcp

Pass --cli to run the Python CLI through the same package:

npx ews-meeting-mcp --cli env
npx ews-meeting-mcp --cli calendar --days 7

Suggest a 30-minute meeting slot:

npx ews-meeting-mcp --cli suggest \
  --attendee alice@company.com \
  --attendee bob@company.com \
  --start 2026-06-15T09:00:00+08:00 \
  --end 2026-06-19T18:00:00+08:00 \
  --duration-minutes 30 \
  --limit 5

Preview a meeting invitation without sending anything:

npx ews-meeting-mcp --cli create-meeting \
  --attendee alice@company.com \
  --attendee bob@company.com \
  --start 2026-06-15T11:00:00+08:00 \
  --end 2026-06-15T11:30:00+08:00 \
  --subject "Project sync" \
  --body "Discuss next steps" \
  --location "Webex"

Actually create the meeting and send invitations:

npx ews-meeting-mcp --cli create-meeting \
  --attendee alice@company.com \
  --attendee bob@company.com \
  --start 2026-06-15T11:00:00+08:00 \
  --end 2026-06-15T11:30:00+08:00 \
  --subject "Project sync" \
  --body "Discuss next steps" \
  --location "Webex" \
  --confirm

The --confirm flag is intentionally required. Without it, the command prints a dry-run preview and does not call EWS to create the event.

Local Development

For detailed setup, smoke tests, CLI examples, and MCP client configuration, see the Usage Guide.

The short development loop is:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
npm test

Run the MCP server from a checkout:

env PYTHONPATH=src python -m ews_meeting_mcp.mcp_server

Companion Skill

The repo includes a companion skill for agents that support skills:

skills/ews-meeting-mcp/SKILL.md

See the Agent Guide for the same workflow in plain Markdown.

Troubleshooting

Operational troubleshooting lives in the Usage Guide. For agent behavior, setup-check handling, and lifecycle safety, see the Agent Guide.

Release

See Publishing.

License

MIT

Available Tools

17 tools

ews_cancel_meeting_confirmedA

Cancel an existing non-recurring organizer meeting by moving it to trash. Requires confirm=true and the confirmation_id returned by ews_cancel_meeting_preview.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Exact EWS calendar item id from ews_find_calendar_events.
`changekey`	Yes	Exact changekey returned with the EWS item id.
`send_meeting_cancellations`	No	When true, send Exchange meeting cancellation notices.
`confirmation_id`	Yes	Must exactly match the confirmation_id returned by ews_cancel_meeting_preview.
`confirm`	Yes	Must be true. The tool refuses to cancel meetings unless confirm=true.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description bears full burden. Mentions move to trash and confirms boolean guard. Doesn't detail cancellation notices or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: purpose and prerequisite. No filler, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a confirmation tool: goal, key params, prerequisite action. No return value details needed. Highlights non-recurring limitation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 5 params with descriptions. Description only echoes confirm and confirmation_id, adding no new meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Describes canceling a non-recurring meeting by moving it to trash. Verb 'cancel' and resource 'organizer meeting' are specific. Distinct from preview sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States prerequisite: requires confirm=true and confirmation_id from preview. Implies workflow after preview. No explicit when-not, but clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_cancel_meeting_previewA

Preview cancellation of an existing meeting using exact id and changekey. Does not delete, move, or send cancellations.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Exact EWS calendar item id from ews_find_calendar_events.
`changekey`	Yes	Exact changekey returned with the EWS item id.
`send_meeting_cancellations`	No	When true, send Exchange meeting cancellation notices.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool does not delete, move, or send cancellations, indicating it is a read-only preview. However, it does not mention any other behavioral traits like whether it modifies state, requires specific permissions, or has rate limits. For a preview tool, the disclosure is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and contains no redundant information. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is fairly complete for a preview tool. However, it does not describe the return value or what the preview actually shows (e.g., list of affected attendees). This is a gap that could be filled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. The description adds value by emphasizing the use of 'exact' id and changekey, and implicitly clarifies that the send_meeting_cancellations parameter is ignored (since it states 'does not send cancellations'). This provides semantic context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Preview cancellation of an existing meeting using exact id and changekey.' It also explicitly states what it does not do ('does not delete, move, or send cancellations'), distinguishing it from siblings like ews_cancel_meeting_confirmed that actually send cancellations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is for previewing before actual cancellation, with the sibling ews_cancel_meeting_confirmed for the actual action. However, it does not explicitly state prerequisites (e.g., need to have the id/changekey from a previous fetch) or scenarios when to choose this over other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_create_meeting_confirmedA

Create a meeting and send invitations. Only call after the user explicitly confirms the exact attendees, time, subject, body, and location. Requires confirm=true and the confirmation_id returned by ews_create_meeting_preview.

ParametersJSON Schema

Name	Required	Description	Default
`subject`	Yes
`attendees`	Yes
`rooms`	No	Meeting room names, aliases, or email addresses.
`start`	Yes	ISO datetime with timezone
`end`	Yes	ISO datetime with timezone
`body`	No
`body_format`	No	Meeting body format. Defaults to html; plain text input is safely converted to HTML.	html
`location`	No
`confirmation_id`	Yes	Must exactly match the confirmation_id returned by ews_create_meeting_preview.
`confirm`	Yes	Must be true. The tool refuses to create meetings unless confirm=true.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states the tool sends invitations (destructive) and requires confirm=true and matching confirmation_id. It doesn't mention side effects like email notifications or idempotency, but the core behavior is disclosed clearly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second gives usage condition. No redundant information. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, 6 required, and no output schema, the description covers purpose, prerequisite (preview), and required flags. It does not describe return value or error cases, but for a create tool with sibling preview, this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 60% and already documents most parameters. The description adds context that confirmation_id must match the one from ews_create_meeting_preview and that confirm must be true. This adds semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Create a meeting and send invitations', providing a specific verb and resource. It distinguishes from sibling tools like ews_create_meeting_preview (preview step) and ews_update_meeting_confirmed (update vs create).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Only call after the user explicitly confirms the exact attendees, time, subject, body, and location' and specifies required parameters confirm and confirmation_id. This gives clear when-to-use guidance and implies when not to use (before user confirmation).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_create_meeting_previewB

Preview a meeting invite without creating the event or sending invitations.

ParametersJSON Schema

Name	Required	Description	Default
`subject`	Yes
`attendees`	Yes
`rooms`	No	Meeting room names, aliases, or email addresses.
`start`	Yes	ISO datetime with timezone
`end`	Yes	ISO datetime with timezone
`body`	No
`body_format`	No	Meeting body format. Defaults to html; plain text input is safely converted to HTML.	html
`location`	No

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. Only hints at non-destructive behavior ('without creating'). Does not disclose what information the preview returns, whether it checks availability, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single focused sentence with no wasted words. Front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 8 parameters and no output schema, description is too sparse. Does not hint at return value, usage patterns, or how to interpret results. Incomplete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 50% of parameters with descriptions. Description adds no additional meaning; critical required params like 'subject' and 'attendees' lack explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it previews a meeting invite without creating or sending, using specific verbs and resource ('preview', 'meeting invite'). Distinguishes from sibling 'ews_create_meeting_confirmed' which creates the event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like 'ews_update_meeting_preview' or 'ews_resolve_attendees'. Lacks context for prerequisites or use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_find_calendar_eventsA

Read-only search for calendar events in a time window. Returns exact EWS id and changekey metadata for safe preview-confirm update or cancel flows.

ParametersJSON Schema

Name	Required	Description
`start`	Yes	ISO datetime with timezone
`end`	Yes	ISO datetime with timezone
`subject_contains`	No	Optional case-insensitive subject filter.
`location_contains`	No	Optional case-insensitive location filter.
`organizer_email`	No	Optional exact organizer email filter.
`attendee_email`	No	Optional exact attendee or resource email filter.
`limit`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clearly labels the tool as 'Read-only' and specifies return metadata (id and changekey), but does not cover authorization requirements or potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, each adding value: first sentence defines purpose and nature, second sentence details return metadata. No redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 7 parameters and no output schema, the description covers key behavioral aspects (read-only, return metadata). It lacks details on pagination or error handling, but the schema fills in parameter specifics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 86%, and the schema already has detailed descriptions for each parameter. The description adds minimal new meaning beyond stating 'time window' for start/end. No further parameter guidance is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides a specific verb ('search') and resource ('calendar events'), clearly distinguishing this read-only tool from sibling mutation tools like ews_create_meeting_confirmed. It explicitly mentions the EWS id and changekey metadata, which are unique to this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the tool is for 'safe preview-confirm update or cancel flows,' giving context for when to use it. However, it does not explicitly exclude other scenarios or compare with siblings like ews_suggest_slots or ews_get_free_busy.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_get_audit_logA

Read recent local lifecycle audit entries for meeting preview, confirmed, duplicate, in-progress, and error actions. Does not read EWS credentials or call Exchange.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`action`	No	Optional action filter such as create_meeting, update_meeting, or cancel_meeting.
`status`	No	Optional status filter: preview, confirmed, duplicate, in_progress, or error.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It reveals read-only behavior and explicitly states no external calls or credential reading. It does not cover limit behavior or return format, but given the simplicity, it is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences with no redundant information. The first sentence front-loads the purpose, and the second clarifies a key behavioral aspect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters and no output schema, the description covers purpose and read-only nature but omits expected return format or pagination behavior. It is adequate but incomplete for a fully self-contained description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67% (two of three parameters have descriptions). The description does not add meaning beyond the schema; it only restates the action and status filters without extra detail. The 'limit' parameter is left undocumented in schema and description, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read' and the resource 'recent local lifecycle audit entries for meeting preview, confirmed, duplicate, in-progress, and error actions.' It also distinguishes from other tools by noting it does not read EWS credentials or call Exchange.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage (reading local audit entries) and hints that it is not for Exchange operations. However, it does not explicitly state when to use it vs. alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_get_free_busyA

Read free/busy blocks for one or more attendee email addresses.

ParametersJSON Schema

Name	Required	Description
`attendees`	Yes
`start`	Yes	ISO datetime with timezone
`end`	Yes	ISO datetime with timezone

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes operation as 'Read', indicating non-destructive behavior. No annotations provided, so description carries full burden; lacks details on rate limits, error handling, or data freshness aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb and resource, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description does not explain the format of free/busy blocks. However, the tool name is self-explanatory and sibling tools exist for richer context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema by clarifying that 'attendees' are email addresses. Schema coverage is 67% (start and end have descriptions), but description compensates by specifying 'attendee email addresses' for the first parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Read free/busy blocks' with specific resource (attendee email addresses). Distinguishes from siblings like ews_suggest_slots (suggest times) and ews_find_calendar_events (events).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for reading free/busy blocks, but no explicit guidance on when to use vs alternatives like ews_find_calendar_events or ews_suggest_slots.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_keychain_statusA

Check whether EWS password credentials are available from environment variables or macOS Keychain without revealing the password. If missing, returns required_action and setup_command that must be shown verbatim to the user.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description responsibly discloses that the tool does not reveal the password and returns required_action and setup_command if credentials are missing. It could further clarify the return format when credentials are present, but the safety and action implications are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that front-loads the main purpose and includes a critical usage instruction. Every word adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless tool with no output schema, the description sufficiently covers purpose, behavioral constraints, and required user action. The agent can correctly select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and the schema coverage is 100%. The description does not need to add parameter details. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks EWS password credential availability from environment variables or macOS Keychain without revealing the password. It specifies the resource and action, and implicitly distinguishes from siblings like ews_setup_check by focusing on credential status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use (to check credentials) and provides an important usage note: the returned setup_command must be shown verbatim. However, it does not explicitly state when not to use or suggest alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_list_calendarC

List upcoming events from the configured user's default calendar.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description does not disclose behavioral traits like read-only nature, authentication needs, or return format. Only states the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words, but it omits critical information, making it less useful despite brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, and no annotations, the description is severely incomplete. It does not explain the 'days' parameter, the output format, or usage restrictions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The 'days' parameter (integer, default 7, minimum 1) is not mentioned in the description. With 0% schema coverage, the description fails to add any meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (list) and resource (upcoming events from the configured user's default calendar). Differentiates from sibling tools like ews_list_rooms and ews_find_calendar_events through specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings such as ews_find_calendar_events. Does not mention alternatives or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_list_roomsB

List Exchange meeting rooms from dynamic room lists, or configured static fallback rooms, as structured options for user selection.

ParametersJSON Schema

Name	Required	Description	Default
`attendee_count`	No	Optional attendee count used to hide rooms with known insufficient capacity.
`query`	No	Optional text filter matched against room name, email, alias, or room list.
`room_list`	No	Optional Exchange room list name or email to search within.
`source`	No	auto tries Exchange and falls back to configured rooms; static never requires credentials.	auto
`limit`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions two sources (Exchange and static) and hints at credentials (static never requires them), but does not disclose rate limits, error handling, authentication requirements for the Exchange path, or what happens when no rooms are found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence (18 words) that front-loads the action and key differentiators. It earns its place without fluff, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks an explanation of the return format, which is important given no output schema. While the tool's parameters and sources are covered, the vague 'structured options' does not fully inform the agent about what to expect, such as properties of room objects or pagination.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, baseline is 3. The description adds some value beyond schema by clarifying that attendee_count hides rooms with insufficient capacity and that 'static' source never requires credentials. However, most parameter descriptions are similar to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List', the resource 'Exchange meeting rooms', and differentiates between dynamic room lists and static fallback. It also mentions the output as 'structured options for user selection', which distinguishes it from sibling tools that handle meetings, calendar events, or audits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. Given the 16 sibling tools, there is no mention of when not to use it or which other tools might be more appropriate for related tasks like finding free slots or resolving attendees.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_probeA

Check that the configured EWS account can connect. Does not read calendar items.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states it checks connectivity and does not read calendar items, which is transparent but limited. It could be improved by explicitly stating that it makes a test connection and indicating no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no extraneous information. The primary action is front-loaded, and the 'does not' clarification is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple connectivity check with no parameters and no output schema, the description is mostly complete. It covers what the tool does and what it does not do. Minor improvement could mention expected output or typical result (e.g., success/failure indicator).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so the description adds no parameter-specific information. According to calibration, a baseline score of 4 is appropriate for zero-parameter tools with 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Check' and the resource 'configured EWS account can connect,' making the tool's purpose unambiguous. It also explicitly says 'Does not read calendar items,' which distinguishes it from many sibling tools that operate on calendar data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for verifying connectivity but does not provide explicit guidance on when to use this tool versus alternatives. It includes a negative statement about not reading calendar items, which helps prevent misuse, but lacks prerequisites or context for when this probe is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_resolve_attendeesA

Resolve attendee names, aliases, or email addresses against the company Exchange directory before scheduling. If multiple matches are returned, ask the user which email to use.

ParametersJSON Schema

Name	Required	Description	Default
`attendees`	Yes	Attendee display names, aliases, or email addresses.
`limit`	No

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains the resolution process but does not disclose side effects, permissions, or behavior on no match. Adequate but could be more thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. Front-loaded with the core purpose, followed by direct usage guidance. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple directory resolution tool with no output schema, the description covers purpose and key usage. However, it omits what happens if no match is found and the format of the returned data. Adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% only for 'attendees', and the description repeats that info. The 'limit' parameter lacks description in both schema and description, leaving its purpose unclear. Description fails to compensate for low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool resolves attendee names against a company Exchange directory, with specific verb 'Resolve' and resource 'attendees, aliases, or email addresses'. Distinct from sibling tools that handle meetings and calendar events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions 'before scheduling' as the context and instructs to ask the user if multiple matches occur. Does not explicitly exclude alternatives, but sibling tools don't offer similar functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_setup_checkA

Return whether EWS setup is ready, including env and password/Keychain checks. When ready is false, show user_message or setup_command and stop before scheduling.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a ready flag and, if false, provides user_message or setup_command. This is adequate for a simple check tool, though it does not detail error handling or throttling, which are likely not applicable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using two sentences that front-load the purpose and then provide actionable guidance. Every sentence adds value and there is no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has zero parameters and no output schema, the description is complete. It explains the tool's role in the EWS workflow (setup check before scheduling) and what information it provides (ready flag, user_message/setup_command). No additional details are needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so the description adds meaning beyond the empty schema by explaining what the tool returns and the conditions under which it returns different values. This helps the agent understand the tool's behavior without needing an output schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Return whether EWS setup is ready', and specifies the checks performed (env and password/Keychain). It distinguishes itself from sibling tools which focus on meetings and calendar operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implicit usage guidance by saying 'stop before scheduling when ready is false', indicating the tool should be used before scheduling operations. It does not explicitly mention when not to use it or list alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_suggest_slotsA

Suggest nearest overlapping free meeting slots for multiple attendees and optional candidate meeting rooms. Omits workday_start, workday_end, and avoid to use local policy defaults.

ParametersJSON Schema

Name	Required	Description
`attendees`	Yes
`start`	Yes	ISO datetime with timezone
`end`	Yes	ISO datetime with timezone
`rooms`	No	Candidate meeting rooms. Supports aliases like 2-11, 2-13, 2-14, 3-1, 3-2, 3-4.
`require_room`	No	When true and rooms is empty, search Exchange room lists when available, then fall back to configured static rooms and filter by capacity.
`duration_minutes`	No
`limit`	No
`workday_start`	No	HH:MM. Omit to use local policy default.
`workday_end`	No	HH:MM. Omit to use local policy default.
`avoid`	No	HH:MM-HH:MM ranges. Omit to use local policy default.

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It mentions using local policy defaults for workday_start, workday_end, and avoid, but lacks details on time zone handling, error conditions, or performance traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences) and front-loaded with the main purpose. It could be slightly more structured but is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters and no output schema, the description is insufficient. It does not explain return format, how conflicts are resolved, or what 'nearest overlapping' means in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 70%, so parameter descriptions exist. The description adds context about defaulting omitted parameters to local policy, but does not significantly extend beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool suggests nearest overlapping free meeting slots for multiple attendees and optional rooms, which distinguishes it from siblings like ews_get_free_busy or ews_find_calendar_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for finding free slots but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_update_meeting_confirmedA

Update an existing meeting. Requires confirm=true and the confirmation_id returned by ews_update_meeting_preview. Supports only subject, start, end, location, and body.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Exact EWS calendar item id from ews_find_calendar_events.
`changekey`	Yes	Exact changekey returned with the EWS item id.
`subject`	No	Optional replacement subject.
`start`	No	Optional replacement ISO datetime with timezone.
`end`	No	Optional replacement ISO datetime with timezone.
`location`	No	Optional replacement location.
`body`	No	Optional replacement body.
`body_format`	No	Format for body updates. Defaults to html; plain text input is safely converted to HTML.	html
`send_meeting_invitations`	No	When true, the confirmed update sends Exchange meeting update notifications.
`confirmation_id`	Yes	Must exactly match the confirmation_id returned by ews_update_meeting_preview.
`confirm`	Yes	Must be true. The tool refuses to update meetings unless confirm=true.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses key requirements (confirm=true, confirmation_id) and field limitations, but it does not mention behavioral traits such as the default sending of meeting invitations, permission needs, or idempotency. Some transparency is present but gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and immediately provide essential requirements and limitations. Every sentence contributes meaning without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 11 parameters (4 required) and no output schema, the description covers the core workflow (preview then confirmed) and lists updatable fields. It lacks details on return behavior or the send_meeting_invitations parameter, but it is sufficiently complete for the primary use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). The description adds value by emphasizing that only subject, start, end, location, and body are supported for updates, which clarifies the role of id and changekey as identifiers. This context goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Update an existing meeting' and the specific resource. It distinguishes from sibling tools like ews_update_meeting_preview by emphasizing the confirmed step, and it lists the limited set of supported fields, making the purpose highly specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: after obtaining confirmation_id from ews_update_meeting_preview and with confirm=true. It provides clear context but does not explicitly exclude other sibling tools like create or cancel, though the name and description imply the use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_update_meeting_previewA

Preview changes to an existing meeting using exact id and changekey. Does not save or send meeting updates.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Exact EWS calendar item id from ews_find_calendar_events.
`changekey`	Yes	Exact changekey returned with the EWS item id.
`subject`	No	Optional replacement subject.
`start`	No	Optional replacement ISO datetime with timezone.
`end`	No	Optional replacement ISO datetime with timezone.
`location`	No	Optional replacement location.
`body`	No	Optional replacement body.
`body_format`	No	Format for body updates. Defaults to html; plain text input is safely converted to HTML.	html
`send_meeting_invitations`	No	When true, the confirmed update sends Exchange meeting update notifications.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description clearly discloses the primary behavioral trait: no save or send. It adds context about requiring exact id and changekey. Could mention any temporary state changes or whether the preview modifies anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no fluff. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 9 parameters and no output schema, yet the description does not specify what the preview returns (e.g., a diff, a summary). This leaves the agent uncertain about the output format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description reiterates the required parameters ('exact id and changekey') but does not add new meaning or clarify how parameters affect the preview output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific language: 'Preview changes to an existing meeting using exact id and changekey.' It clearly distinguishes from siblings like ews_update_meeting_confirmed by stating it does not save or send updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the tool is for previewing and does not save/send, which guides appropriate use. However, it does not explicitly name the confirmed sibling as the alternative for actual updates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ews_verify_meetingA

Verify a calendar item by EWS id and optional changekey. Returns normalized organizer item status, attendees, rooms/resources, and response_status values when Exchange exposes them.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	EWS calendar item id returned by create or search.
`changekey`	No	Optional changekey returned by create, search, update, or cancel preview.

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It lists returned data but does not state side effects, read-only nature, or authentication requirements. It adds some context but has gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence conveys purpose and outputs clearly without unnecessary words. Well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should cover return values. It lists them but not complete specifics. Could mention error behavior or typical use cases. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds context beyond schema: explains that id comes from create/search and changekey from create/search/update/cancel preview, providing useful source information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a calendar item by EWS id and changekey, using a specific verb and resource. Among siblings with verbs like create, update, cancel, find, 'verify' is unique and distinguishes this tool's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like ews_find_calendar_events or ews_probe. No explicit context or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

All tools have clearly distinct purposes, with preview/confirmed pairs clearly differentiated and supporting tools (find, list, resolve, suggest) addressing separate needs. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'ews_verb_noun' pattern, with clear conventions for preview vs confirmed flows (e.g., ews_create_meeting_preview, ews_create_meeting_confirmed). No naming irregularities.

Tool Count5/5

17 tools is well-scoped for a meeting management server, covering setup, inspection, scheduling, creation, update, cancellation, and verification. Each tool serves a distinct and necessary function.

Completeness5/5

The tool surface covers the full lifecycle of meeting management from setup and attendee resolution to create/update/cancel with preview/confirmed flows, plus supporting tools like free/busy, room listing, and audit log. No obvious gaps for an organizer-focused server.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

BusyBoard
app.busyboard
Merged free/busy, find mutual time, propose bookings with human approval. Never event contents.
Calendar Management Workplace & Productivity
1
M365 Graph MCP B
work.mcps
Manage Microsoft 365 email, calendar, contacts and inbox rules via the Graph API with OAuth 2.0.
Email Calendar Management Workplace & Productivity
2
microsoft-365
com.proscendia
Permissioned access to Outlook, OneDrive and Teams via the user's own Microsoft account
Email Cloud Storage Communication
1
WhenMeet.me — group scheduling A
me.whenmeet
Group meeting scheduler — rank times everyone's free across Google & Outlook, book Meet/Teams.
Calendar Management Workplace & Productivity
82

Related MCP Servers

Outlook Meetings Scheduler MCP
Calendar Management Communication App Automation
anoopt
A
license
A
quality
D
maintenance
Allows scheduling meetings in Microsoft Outlook using Microsoft Graph API, with features for creating calendar events and adding attendees by finding their email addresses.
Updated 8 months ago (2025-12-24 12:15 UTC)
8
28
16
ISC
MCP Outlook Scheduler
Calendar Management Workplace & Productivity
ChitSingh
F
license
Not graded
quality
D
maintenance
Enables AI assistants to intelligently schedule meetings by checking Microsoft Outlook calendars, finding available time slots across multiple participants, and automatically booking meetings with Teams integration. Uses Microsoft Graph API with smart fallback logic for optimal scheduling.
Updated a year ago (2025-08-16 19:44 UTC)
1
-
Google MCP Router
Calendar Management Communication App Automation
Thinh-nguyen-03
-
license
Not graded
quality
Not graded
maintenance
Enables scheduling meetings and sending email confirmations through Google Calendar and Gmail APIs. Provides secure OAuth authentication, policy enforcement for working hours, and prevents scheduling conflicts.
Updated a year ago (2025-09-29 03:55 UTC)
-
OWA Exchange MCP Server
Email Calendar Management
nhype
A
license
A
quality
D
maintenance
MCP server for any Microsoft Exchange / OWA deployment. Gives LLM agents access to email, calendar, directory search, folders, availability, and meeting analytics via 30 tools.
Updated 7 months ago (2026-02-16 07:05 UTC)
30
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ap311036/ews-meeting-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server