What can you do with this server?

This server enables controlling the Microsoft Outlook desktop app via COM automation — managing emails, calendar events, and contacts without needing a cloud API or Azure registration. Requires Windows with the classic Outlook desktop app (not the new Outlook). Email – Read & Search * List all mail folders across every account/store * List recent emails (with optional unread-only filter) and read full email content by EntryID * Search emails by subject, sender, body, or all fields * List and save attachments to a local directory Email – Write & Management * Send new emails (with CC/BCC, HTML body, file attachments, or scheduled delivery) or save as draft * Reply, reply-all, or forward emails, optionally saving as draft * Manage drafts (list, update, send, delete) * Mark emails as read/unread, move to folders, or delete Calendar & Scheduling * List, search, and retrieve full details of calendar events * Create appointments, meeting invites, Teams meetings, and recurring meetings * Update or cancel events (single occurrences or full series) * Check attendee availability and find common free meeting times * Schedule Out-of-Office status on the calendar * Read shared calendars Meeting Invitations * List pending meeting invitations and respond (accept/tentative/decline) Contacts & Accounts * List and search contacts by name, email, or company * List all configured sending accounts and mail stores Other * Recipient validation (resolves names, rejects ambiguous ones unless overridden) * Explicit timezone handling for meeting creation * Outlook health diagnostics * Items addressed by Outlook EntryID; folders referenced by name (e.g. Inbox) or slash path (e.g. Inbox/Receipts) Note: Cannot directly set automatic email replies (auto-responder); Teams meeting link injection depends on Outlook settings.

How do I use outlook-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@outlook-mcp Show my unread emails" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

outlook-mcp

by jagarlamudisrinath

Overview Schema Source Related Servers Discussions Admin

Python

Local

Outlook MCP Server (win32com)

An MCP server that controls the Microsoft Outlook desktop app through COM automation (win32com). It does not use Microsoft Graph — there is no Azure app registration, no OAuth, no API keys. It operates on whatever account(s) your local Outlook client is already signed into, which makes it ideal for corporate environments where Graph API access is locked down.

Requirements

Windows (COM automation is Windows-only)
Classic Outlook desktop installed and configured with an account. The "new Outlook" (the web-based rewrite) does not expose the COM object model and will not work — switch the toggle back to classic Outlook.
Python 3.10+

Related MCP server: outlook-classic-mcp

Installation

git clone <this-repo>
cd outlook_mcp
pip install -e .

This installs mcp and pywin32 and registers the outlook-mcp command.

Configure Claude Desktop / Claude Code

Claude Desktop (%APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "outlook": {
      "command": "outlook-mcp"
    }
  }
}

Claude Code:

claude mcp add outlook -- outlook-mcp

If Outlook is not running, the first tool call starts it automatically.

Tools

Mail — read & search

Tool	Description
`list_folders`	Tree of all mail folders across every account/store
`list_emails`	Recent emails in a folder (newest first, optional unread-only)
`get_email`	Full email by `entry_id` — SMTP addresses, headers, HTML, links, Message-ID
`search_emails`	Filtered search: text, sender/recipient, date range, unread/flagged/importance/attachments, across all folders or subfolders
`list_attachments`	List an email's attachments (index, size, inline vs. real, MIME)
`save_attachments`	Save attachments safely (sanitized names, no collisions, size limit, SHA-256)

Mail — write, drafts & management

Tool	Description
`send_email`	Send/draft — HTML, attachments, importance/sensitivity/categories, send-as/on-behalf, scheduled delivery, read receipt
`reply_to_email`	Reply / reply-all — HTML, attachments
`forward_email`	Forward — CC/BCC, validated recipients, attachments
`list_drafts`	List messages in the Drafts folder
`update_draft`	Edit a saved draft (subject/body/recipients/attachments)
`send_draft`	Send an existing draft (re-validates recipients)
`delete_draft`	Delete a draft
`remove_attachment`	Remove one attachment from a draft/item
`mark_email`	Mark read / unread
`move_email`	Move an email to another folder
`delete_email`	Move an email to Deleted Items

Calendar & scheduling

Tool	Description
`list_calendar_events`	Events in a window around today (recurrences expanded)
`get_calendar_event`	Full event details — attendees + responses, recurrence, join links, categories
`search_calendar_events`	Filter events by subject/organizer/location/category/Teams/recurring/attachments
`create_calendar_event`	Create an appointment or send a meeting invite (timezone-aware)
`create_teams_meeting`	Send a meeting invite (Teams link via org setting, see below)
`create_recurring_meeting`	Send a recurring series (daily/weekly/monthly/yearly, timezone-aware)
`update_calendar_event`	Update a whole event/series; add/remove attendees, optionally re-invite
`update_single_occurrence`	Edit one occurrence of a recurring series
`cancel_calendar_event`	Cancel a meeting you organize (notifies attendees)
`cancel_single_occurrence`	Cancel one occurrence of a series
`delete_calendar_event`	Delete an event with no notice
`check_availability`	Show attendees' free/busy timeline for a day
`find_meeting_times`	Find slots when all attendees are free, across a date range
`schedule_out_of_office`	Block your calendar with Out-of-Office status
`set_automatic_replies`	Guidance only — auto-replies aren't COM-settable (see below)

Meeting invitations, contacts & accounts

Tool	Description
`list_meeting_invitations`	Meeting requests in your Inbox — response state + calendar conflicts
`respond_to_invitation`	Accept / tentative / decline an invitation
`list_shared_calendar`	Read another person's calendar (if shared to you)
`list_contacts`	List/search the default Contacts folder
`list_accounts`	List sending accounts and mail stores in the profile
`outlook_health`	Diagnostics: Outlook version, user, store, connection mode

Emails and events are addressed by their Outlook EntryID, which the list/ search tools return — pass it to get_email, reply_to_email, update_calendar_event, etc. Folders accept well-known names (Inbox, Sent Items, Drafts, ...) or slash paths like Inbox/Receipts or you@company.com/Inbox to target a specific account.

Example prompts

"Show my unread emails"
"Search my inbox for emails from Alice about the Q3 budget"
"Reply to that email saying I'll review it by Friday"
"Save the attachments from that email to C:\Users\me\Downloads"
"What's on my calendar this week?"
"Check if alice@corp.com and bob@corp.com are free Thursday afternoon"
"Find a 30-minute slot next Monday when the whole team is available"
"Set up a 30-minute meeting with bob@example.com tomorrow at 2pm"
"Mark me out of office next Friday through the following Wednesday"

Time zones (recommended for meetings)

The meeting-creation tools (create_calendar_event, create_teams_meeting, create_recurring_meeting) accept an optional timezone_name. Give it an IANA name (Asia/Kolkata), a Windows ID (India Standard Time), or a common abbreviation (IST). The start time you pass is treated as wall-clock time in that zone, and the result reports both the local and UTC times.

This matters most for recurring meetings: without an explicit zone, a series pinned to "12:00" can shift by an hour when it crosses a daylight-saving boundary, because Outlook interprets the time in whatever zone the profile happens to be in. Passing timezone_name sets the appointment's StartTimeZone/EndTimeZone in COM so occurrences stay put. (Note: on Windows, Python needs the tzdata package for this — it's declared as a dependency.)

Recipient validation

send_email (and the meeting tools) add each recipient individually and call ResolveAll() before sending. If any name is ambiguous or unknown, the send is rejected with the offending entries listed — pass allow_unresolved=True to override. Results list every recipient's canonical SMTP address (Exchange EX addresses are resolved to real SMTP), so you can confirm exactly who will receive the message before trusting it.

Development & tests

pip install -e ".[dev]"
pytest

The pure-logic layer (date/timezone parsing, DST conversion, recurrence, recipient resolution) is covered by mock-based tests that run on any platform — no Windows or Outlook required. COM interaction itself can only be exercised on Windows. CI runs the suite on Python 3.10–3.12.

Checking other people's availability

check_availability and find_meeting_times read free/busy data — the same busy/free blocks Outlook shows in the Scheduling Assistant. In most Exchange/Microsoft 365 organizations every user can see everyone else's free/busy by default (busy times only, not the meeting subjects), so no special mailbox permissions are needed. If a person has restricted their free/busy sharing, their slots come back as unavailable and the tools say so.

Teams meetings and invitations

Responding to invites works fully. list_meeting_invitations shows pending requests in your Inbox; respond_to_invitation accepts, tentatively accepts, or declines them (with an optional note, and an option to respond without notifying the organizer).
Reading others' meetings (list_shared_calendar) works when that person has shared their calendar with you at Reviewer permission or higher. It shows real subjects/times, unlike check_availability, which shows only free/busy.
Creating a Teams meeting is partial. COM cannot inject a Teams join link — the link is produced by the Teams Meeting Add-in/service, not the Outlook Object Model. create_teams_meeting sends the invite and relies on the mailbox setting File > Options > Calendar > "Add online meeting to all meetings"; with that ON, sent meetings automatically become Teams meetings. With it OFF, an ordinary meeting invite is sent and you'd add the Teams link manually.
"Propose new time" is not available via COM. The Object Model has no propose-new-time method. To suggest another slot, decline with a message (or use find_meeting_times to pick a slot and send a fresh invite).
Recurring meetings are supported. create_recurring_meeting sends a full series — daily, weekly (with specific weekdays like Mon,Wed,Fri), monthly, or yearly, with an interval (e.g. every 2 weeks) and an end defined by a number of occurrences (count) or an end date (until). Attendees receive the series and accept it as a series. Recurring invites you receive are accepted/declined as a whole series by respond_to_invitation.

Out of office: what works and what doesn't

schedule_out_of_office works — it creates a calendar block with "Out of Office" availability status, so you show as away in other people's free/busy and Scheduling Assistant.
Automatic replies (the auto-responder email) cannot be set via COM. The Outlook Object Model simply does not expose Out-of-Office reply settings. set_automatic_replies therefore only returns guidance. To turn on the auto-responder, either flip it on manually (File > Automatic Replies) or use Exchange Web Services (SetUserOofSettings) / Microsoft Graph (mailboxSettings.automaticRepliesSetting) — both of which are outside COM.

Notes & troubleshooting

Security prompts: depending on your organization's policy, Outlook may show an "Allow access?" dialog when a program reads addresses or sends mail programmatically. Your admin controls this via Group Policy ("Programmatic Access" settings in Trust Center).
"New Outlook" toggle: if tool calls fail with "class not registered" or Outlook opens but nothing happens, you are likely on new Outlook. Switch back to classic Outlook.
Bitness/permissions: run the MCP server as the same user (and not elevated differently) as Outlook, or COM will refuse to connect to the running instance.

Available Tools

14 tools

create_calendar_eventA

Create a calendar event, optionally sending invites to attendees.

Args: subject: Event title. start: Start time as "YYYY-MM-DD HH:MM". duration_minutes: Length of the event in minutes. location: Optional location. body: Optional description. attendees: Optional semicolon-separated attendee addresses; if given, the event is sent as a meeting invitation.

ParametersJSON Schema

Name	Required	Description	Default
`body`	No
`start`	Yes
`subject`	Yes
`location`	No
`attendees`	No
`duration_minutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/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 mentions optional invite sending when attendees are given, but does not disclose permissions, side effects, or what happens upon success. While adequate, it lacks deeper behavioral context.

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 docstring format is concise and well-structured, with a clear overview and numbered parameter descriptions. Every sentence is necessary and adds value, with no redundancy.

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 presence of an output schema (which handles return values), the description is complete for a create operation. It covers all parameters and core behavior. Minor gap: no mention of prerequisites or confirmation of event creation, but overall sufficient.

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

Parameters5/5

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

Schema description coverage is 0%, but the description fully explains each parameter: subject (title), start (format), duration_minutes (length), location/body (optional), attendees (semicolon-separated triggers invite). It adds format and behavioral details beyond the schema titles.

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 'Create a calendar event' with a specific verb and resource. It distinguishes from siblings like list_calendar_events (read-only) and send_email (different action).

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 explains when to use the attendees parameter (to send invites), providing clear usage context. However, it does not explicitly mention when not to use this tool or provide alternatives, leaving a minor gap.

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

delete_emailC

Delete an email (moves it to Deleted Items).

ParametersJSON Schema

Name	Required	Description	Default
`entry_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations exist, so description carries full burden. It reveals a soft delete behavior (moves to Deleted Items) but omits details like reversibility, permission requirements, or 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.

Conciseness3/5

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

The description is a single sentence, which is concise, but it lacks essential details, making it too minimal. It is front-loaded but at the expense of completeness.

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 having an output schema, the description is inadequate for a 1-parameter tool with no annotations and 0% schema coverage. It does not explain the parameter or behavioral nuances, leaving the agent underinformed.

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?

With 0% schema description coverage and only one parameter (entry_id), the description fails to explain what entry_id represents or how to obtain it, adding no meaning beyond the schema field name.

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 'Delete an email (moves it to Deleted Items)' uses a specific verb and resource, clearly stating what the tool does. It distinguishes from sibling tools like move_email by specifying the destination folder.

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 move_email or mark_email. No prerequisites or exclusion criteria are mentioned.

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

forward_emailA

Forward an email (attachments included).

Args: entry_id: EntryID of the email to forward. to: Recipient address(es), semicolon-separated. comment: Optional text placed above the forwarded message. save_as_draft: Save to Drafts instead of sending.

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`comment`	No
`entry_id`	Yes
`save_as_draft`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

Discloses attachment handling and optional save-as-draft behavior, but with no annotations, the description carries the full burden. Lacks details on delivery guarantees, error handling, or side effects. Meets a basic level but could be more comprehensive.

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?

Description is concise with a clear one-line purpose followed by a structured Args list. No unnecessary words, and the key action is 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?

Covers the main functionality and all parameters. An output schema exists, so the return value is presumably documented. Missing prerequisites or error info, but overall adequate for a simple 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?

Despite 0% schema description coverage, the description's Args section explains each parameter's purpose and format, such as 'semicolon-separated' for the 'to' field and the behavior of 'save_as_draft'. This adds significant value beyond the schema titles.

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 forwards an email with attachments, using a specific verb and resource. It is distinct from sibling tools like send_email or reply_to_email, which handle different email actions.

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 versus alternatives like reply_to_email or send_email. The usage is implied by the tool's name and description, but no exclusions or context are provided.

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

get_emailA

Read a full email by its entry_id (from list_emails/search_emails).

Args: entry_id: The Outlook EntryID of the email. body_max_chars: Truncate the body after this many characters.

ParametersJSON Schema

Name	Required	Description	Default
`entry_id`	Yes
`body_max_chars`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

The description indicates it is a read operation (non-destructive) and mentions body_max_chars truncation. However, with no annotations, it lacks disclosure about error handling, permissions, or other side effects beyond what is inferred.

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 concise: one line for purpose and a clear Args list. Every sentence serves a purpose, no fluff. Front-loaded with the key action.

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 simple 2-parameter tool with an output schema (not shown), the description covers the essential behavioral trait (truncation) and source of entry_id. It is complete enough for an agent to use correctly, though it could mention response format.

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?

With 0% schema description coverage, the description compensates by explaining entry_id's source (from list_emails/search_emails) and body_max_chars's truncation behavior. This adds meaning beyond the schema's title and default.

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 'Read a full email by its entry_id', specifying the verb (read), resource (email), and how to obtain the identifier (from list_emails/search_emails). This distinguishes it from sibling tools like delete_email or forward_email.

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 usage when you have an entry_id from list/search and want full content, but does not explicitly state when not to use or provide alternatives. It is clear but could be more prescriptive.

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

list_calendar_eventsA

List calendar events in a date window around today.

Args: days_ahead: How many days into the future to include. days_back: How many days into the past to include.

ParametersJSON Schema

Name	Required	Description	Default
`days_back`	No
`days_ahead`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided. Description does not disclose ordering, timezone, pagination, or side effects. Minimal transparency for a list tool.

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?

Extremely concise with no redundant information. Two-line description and clear parameter docs. Well-proportioned.

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 tool simplicity, output schema, and zero required params, description is adequate. Minor missing context like timezone but not critical.

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?

Parameter descriptions add meaning beyond schema titles and types, explaining 'days_ahead' and 'days_back' as time windows. Schema coverage is 0%, so description compensates.

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 verb 'list' and resource 'calendar events' with scope 'in a date window around today'. Differentiates from sibling tools like 'create_calendar_event' and other non-calendar tools.

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?

Implies usage for listing events in a date window, but no explicit guidance on when to use vs alternatives or when not to use. Adequate given no conflicting siblings.

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

list_contactsB

List contacts from the default Contacts folder, optionally filtered.

Args: search: Optional substring to match against name/email/company. count: Maximum contacts to return (1-200).

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`search`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It describes filtering and count limits but does not disclose read-only nature, pagination, rate limits, or other behavioral traits. The description is minimal.

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 very concise, with a single sentence for purpose and a structured Args section. Every sentence earns its place; no unnecessary text.

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?

An output schema exists, so return values are covered. However, the description lacks information on default behavior, ordering, or handling of no results. Given 0% schema coverage, it addresses parameters well but misses overall usage completeness.

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 0%, so the description must compensate. It provides clear, helpful details: 'search' matches name/email/company, 'count' is max (1-200). This adds significant value beyond the schema's type/title.

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?

The description clearly states it lists contacts from the default Contacts folder with optional filtering. It distinguishes from sibling tools (all email/calendar), but could be more specific about what 'contacts' refers to (e.g., address book).

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 when-to-use or alternatives are given. Since there are no other contact tools among siblings, it is implied this is the only contact list tool, but no guidance on when not to use or context conditions.

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

list_emailsA

List recent emails in a folder, newest first.

Args: folder: Folder name or path, e.g. "Inbox", "Sent Items", "Inbox/Receipts". count: Maximum number of emails to return (1-100). unread_only: Only return unread emails.

ParametersJSON Schema

Name	Required	Default
`count`	No
`folder`	No	Inbox
`unread_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior2/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 only describes listing behavior without mentioning side effects, permissions, or rate limits. For a read operation, stating 'read-only' would be beneficial.

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 concise, front-loading the purpose and then listing parameter details in a structured format. Every sentence adds value with 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?

Given the tool's simplicity (3 parameters, none required), the description fully covers functionality. An output schema exists, so return value details are not needed.

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

Parameters5/5

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

With 0% schema description coverage, the description compensates fully by explaining each parameter: folder examples, count range (1-100), and unread_only boolean meaning. This adds significant value beyond the schema's type/default info.

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 'List recent emails in a folder, newest first,' which is a specific verb+resource combination. It effectively distinguishes from sibling tools like search_emails or get_email.

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 example folder names and parameter ranges, offering clear context for usage. However, it does not explicitly contrast with siblings like search_emails or specify when not to use this tool.

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

list_foldersA

List all mail folders across every account/store in Outlook.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/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 full burden. It implies a read-only, non-destructive operation but lacks details on potential performance impact, whether folders are returned recursively, or if there are 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 sentence, no wasted words, front-loaded with the action and scope.

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 zero parameters and an existing output schema, the description is minimal but sufficient for a simple listing. However, it could mention whether the listing includes subfolders or only top-level.

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?

Since there are no parameters, the description need not add parameter info. Baseline is 4 for 0-param tools.

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 a specific verb and resource ('list mail folders') and clearly distinguishes this tool from siblings like list_calendar_events or list_emails by specifying 'across every account/store in Outlook'.

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 states what the tool does but provides no guidance on when to use it versus alternatives (e.g., using filters) or any prerequisites.

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

mark_emailB

Mark an email as read or unread.

ParametersJSON Schema

Name	Required	Description	Default
`read`	No
`entry_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It only says 'mark an email as read or unread' with no detail on idempotency, reversibility, permissions, or error states (e.g., missing email). Minimal context beyond the basic action.

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 with no filler, perfectly concise. Every word 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 toggle with an output schema (not shown), the description is minimally sufficient. However, it could mention that the email must exist or what happens on invalid input. Lacks completeness for robustness.

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 0%, so description must compensate. 'read or unread' hints at the 'read' parameter's purpose, but 'entry_id' is completely unexplained. No mention of defaults or required fields.

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 the action ('mark an email') and the binary state ('read or unread'), matching the 'mark_email' name. It uniquely identifies this tool among siblings like 'delete_email', 'forward_email', etc.

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 vs alternatives like 'get_email' (to check status) or other mutation tools. No exclusions or prerequisites mentioned.

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

move_emailB

Move an email to another folder.

Args: entry_id: EntryID of the email to move. target_folder: Destination folder name or path.

ParametersJSON Schema

Name	Required	Description	Default
`entry_id`	Yes
`target_folder`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided; description does not disclose side effects (e.g., whether the email is removed from the source folder, permissions needed, or if the operation is reversible). For a mutation tool, more behavioral context is needed.

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?

Extremely concise with a front-loaded verb-noun phrase followed by parameter descriptions. No extraneous text.

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 move operation with an output schema present, the description is adequate but lacks details on error handling, what happens if the target folder doesn't exist, or confirmation of success.

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 0%; description provides basic meaning for both parameters ('EntryID of the email' and 'destination folder name or path'), adding value beyond the schema's type/title, but no format or constraints.

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 'Move an email to another folder' – a specific verb and resource. This distinguishes it from siblings like delete_email (delete) and forward_email (forward).

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 or any prerequisites. The description is purely declarative without usage context.

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

reply_to_emailA

Reply to an email. The original message is quoted below your reply.

Args: entry_id: EntryID of the email to reply to. body: Your reply text. reply_all: Reply to all recipients instead of just the sender. save_as_draft: Save to Drafts instead of sending.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes
`entry_id`	Yes
`reply_all`	No
`save_as_draft`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/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 discloses that the original message is quoted below the reply, and explains the effects of reply_all and save_as_draft (though in parameter list). Does not mention sending disposition or error cases, but adequate for a reply tool.

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?

Description is concise: one sentence for purpose, then a docstring listing parameters with explanations. No 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.

Completeness4/5

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

Given the existence of an output schema (not shown), the description covers main behavior and parameters thoroughly. Could mention that the reply is sent immediately unless save_as_draft is true, but otherwise complete for a simple tool.

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

Parameters5/5

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

Schema description coverage is 0%, but the description includes a docstring that explains each parameter (entry_id, body, reply_all, save_as_draft) with clear semantics beyond the schema titles. Fully compensates for lack of 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 'Reply to an email' which is a specific verb-resource combination. It distinguishes itself from sibling tools like 'send_email' (new email) and 'forward_email' by focusing on replying.

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 use when replying to an existing email, and provides parameter details for reply_all and save_as_draft. However, it does not explicitly exclude other cases like forwarding or sending new emails.

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

save_attachmentsA

Save all attachments of an email to a local directory.

Args: entry_id: The email's EntryID. save_dir: Directory to save into (created if missing).

ParametersJSON Schema

Name	Required	Description	Default
`entry_id`	Yes
`save_dir`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Discloses that the save directory is created if missing, which is useful behavioral info. However, no annotations exist, and the description omits other behaviors like overwrite policy or error handling.

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 short and front-loaded with the main purpose. The 'Args:' section repeats parameter info but adds context. Could be slightly more concise.

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?

Minimally complete for a simple tool. Does not mention return values (though output schema exists), edge cases like no attachments, or behavior for duplicate filenames.

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?

With 0% schema description coverage, the description provides meaningful explanations for both parameters: entry_id as 'The email's EntryID' and save_dir as 'Directory to save into (created if missing)'.

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 it saves all attachments of an email to a local directory, using specific verb and resource. It distinguishes from siblings as there is no other attachment-related tool.

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, or when not to use it. Does not mention prerequisites or context.

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

search_emailsA

Search emails in a folder by subject, sender, or body text.

Args: query: Text to search for. folder: Folder to search in. count: Maximum results (1-100). search_in: One of "subject", "from", "body", "all".

ParametersJSON Schema

Name	Required	Default
`count`	No
`query`	Yes
`folder`	No	Inbox
`search_in`	No	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, any authentication requirements, rate limits, or behavior for empty or large result sets. The description is minimal in behavioral context.

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 concise: a single sentence followed by a clear list of parameters. Every sentence adds value, and the structure is easy to parse.

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 tool has 4 parameters and no annotations, but an output schema exists. The description adequately covers parameters but lacks usage guidelines and behavioral transparency. It is minimally complete for a search tool, but leaves gaps for an agent to infer.

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 0%, but the description includes an 'Args' section that explains the meaning of each parameter: query, folder, count, and search_in (listing allowed values). This adds significant value beyond the schema, which only has titles and defaults.

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: 'Search emails in a folder by subject, sender, or body text.' It uses a specific verb ('Search') and resource ('emails'), and distinguishes from sibling tools like 'list_emails' which likely lists all emails without filtering.

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 explicit guidance on when to use this tool versus alternatives such as 'list_emails' or other search-related functions. The description only implies usage via the action description, but does not provide when-not-to-use or alternative tool references.

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

send_emailA

Send a new email (or save it as a draft) through Outlook.

Args: to: Recipient address(es), separated by semicolons. subject: Email subject. body: Email body text (or HTML if html=True). cc: CC address(es), semicolon-separated. bcc: BCC address(es), semicolon-separated. html: Treat body as HTML. attachments: Absolute paths of files to attach. save_as_draft: Save to Drafts instead of sending.

ParametersJSON Schema

Name	Required	Description	Default
`cc`	No
`to`	Yes
`bcc`	No
`body`	Yes
`html`	No
`subject`	Yes
`attachments`	No
`save_as_draft`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/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. It discloses the draft-saving behavior and HTML support, but lacks details on authentication, size limits, or error handling. Additional context about Outlook integration or constraints would improve transparency.

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 concise: a single introductory sentence followed by a clean bullet list of parameters. Every sentence adds value, and the structure is front-loaded with the main action.

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 8 parameters and no annotations, the description covers all essential aspects. The output schema exists but is not described, which is acceptable for a typical send operation. The sibling tools list provides clear context, and the description is notably complete.

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

Parameters5/5

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

Schema coverage is 0%, so the description fully compensates. It explains each parameter in detail, including semicolon-separated addresses for to/cc/bcc, absolute paths for attachments, and the boolean flags html and save_as_draft. This adds clear meaning beyond the raw 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 'Send' and the resource 'new email', with an alternative action 'save it as a draft'. This distinguishes it from sibling tools like forward_email or reply_to_email, which handle different email 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 implicitly indicates use for new emails or drafts, but does not explicitly specify when to use alternatives like forward or reply. However, the sibling context makes the distinction clear enough.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

14 tool updatesv0.1.0Jul 14, 2026
- First observedcreate_calendar_event
- First observeddelete_email
- First observedforward_email
- First observedget_email
- First observedlist_calendar_events
- First observedlist_contacts
- First observedlist_emails
- First observedlist_folders
- First observedmark_email
- First observedmove_email
- First observedreply_to_email
- First observedsave_attachments
- First observedsearch_emails
- First observedsend_email

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-14 16:05 across 14 tools

Disambiguation5/5

Each tool targets a distinct operation (email, calendar, contacts, folders) with clear boundaries. There is no overlap; for example, 'send_email' and 'reply_to_email' are distinct actions, and 'list_emails' and 'search_emails' serve different purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., create_calendar_event, delete_email, list_folders). The naming is uniform and predictable, making it easy for an agent to infer the action from the name.

Tool Count5/5

With 14 tools, the set is well-scoped for an Outlook integration covering emails, calendar, contacts, and folders. It provides sufficient functionality without being overwhelming or too sparse.

Completeness4/5

Email operations are comprehensive (CRUD, search, forward, reply, mark, move, save attachments). However, calendar and contacts are limited: calendar only has create and list (missing update/delete), contacts only have list. This leaves minor but notable gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

M365 Graph MCP BOAuth
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
sebastianall1977-gmail-mcpOAuth
ai.smithery
Manage Gmail end-to-end: search, read, send, draft, label, and organize threads. Automate workflow…
Communication App Automation Workplace & Productivity
2
Outlook Mail A
io.github.pipeworx-io
Outlook Mail (Microsoft 365) MCP Pack
Email Communication
362
Outlook Contacts A
io.github.pipeworx-io
Outlook Contacts (Microsoft 365) MCP Pack
Communication Workplace & Productivity
352

Related MCP Servers

MCP Outlook
Email Calendar Management
Vince1024
A
license
Not graded
quality
C
maintenance
Enables AI assistants to manage Microsoft Outlook emails, calendar events, contacts, and folders via COM automation.
Updated 8 months ago (2026-01-15 11:15 UTC)
1
MIT
outlook-classic-mcp
Email Calendar Management Communication
anasahmed07
A
license
Not graded
quality
A
maintenance
Enables MCP-aware agents to interact with the classic Outlook desktop client for mail, calendar, contacts, tasks, and Out-of-Office settings via the COM API, without Azure or OAuth.
Updated a month ago (2026-08-06 22:40 UTC)
24
MIT
outlook-mcp
Email Communication
nhantruong96
F
license
Not graded
quality
C
maintenance
Reads and searches your local Microsoft Outlook desktop mailbox via COM, supporting folder listing, message/thread retrieval, attachment saving, bulk export, and draft creation without sending, requiring no OAuth or admin consent.
Updated 22 days ago (2026-08-24 08:26 UTC)
-
outlook-local-mcp
Email Calendar Management Communication
amirulmenjeni
F
license
A
quality
B
maintenance
Enables local automation of classic Outlook for Windows via COM, allowing email search, folder listing, calendar leave block creation, and contact/recipient management without needing cloud APIs or admin approval.
Updated 22 days ago (2026-08-24 02:54 UTC)
8
-