Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@exchange-ai-connector show me my unread emails from today"
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.
An MCP server that lets an AI agent read and act on your Microsoft 365 / Outlook email and calendar, with every state-changing action (sending mail, creating an event) gated by your MCP client's confirmation prompt.
On PyPI: uvx exchange-ai-connector
or pipx install exchange-ai-connector. See Setup.
Tool | Kind | What it does |
| read-only | List messages in a folder (default inbox) |
| read-only | Read one message in full |
| read-only | Read a whole conversation, oldest → newest |
| gated | Send or reply — client confirms first |
| read-only | List upcoming calendar events |
| read-only | Read one event in full |
| read-only | Free/busy for you (+ others) — work/school only |
| gated | Create an event, optionally inviting attendees |
Related MCP server: outlook-mcp
The read-only tools run freely. The two gated tools (send_email,
create_event) are the only ones that change the outside world; they are
annotated as destructive, so your MCP client (e.g. Claude Desktop) shows you the
exact arguments — recipients, subject, body / event details — and waits for your
approval before running. The draft you review is the agent's proposed
arguments; nothing is stored half-sent. Reject and it vanishes.
Account type | Calendar read/create |
| |
Work / school (Microsoft 365) | ✅ | ✅ | ✅ |
Personal (outlook.com / hotmail) | ✅ | ✅ | ❌¹ |
¹ Graph's getSchedule (free/busy) is not available on personal Microsoft
accounts. check_availability returns a readable error there; every other tool
works.
Go to https://entra.microsoft.com → Identity → Applications → App registrations → New registration.
Name: anything (e.g. exchange-ai-connector).
Supported account types: Accounts in any organizational directory (multitenant) and personal Microsoft accounts.
Redirect URI: platform Public client/native (mobile & desktop), value
http://localhost:8400.
Click Register, then copy the Application (client) ID from the overview page — you'll need it below.
In your app → API permissions → Add a permission → Microsoft Graph → Delegated permissions.
Add: Mail.Read, Mail.Send, Calendars.ReadWrite.
Personal account: nothing more — you consent in the browser on first run. Work/school account: a tenant admin may need to click Grant admin consent.
Adding
Calendars.ReadWritelater (e.g. after using email-only) triggers a one-time browser re-consent on the next run. See Re-consent below.
Pick one:
uvx (recommended — no clone, no venv). Requires uv.
Nothing to install ahead of time — uvx fetches and runs the command in a
throwaway environment. It's used directly in the Claude Desktop config below, so
you can skip straight to that section.
pipx — puts the exchange-ai-connector command on your PATH globally:
pipx install exchange-ai-connector
# or an unreleased version straight from source:
pipx install git+https://github.com/wteja/exchange-ai-connectorFrom source (for development):
git clone https://github.com/wteja/exchange-ai-connector
cd exchange-ai-connector
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
which exchange-ai-connector # note this path for the Claude Desktop configexport EXCHANGE_AI_CLIENT_ID="<your-app-client-id>"
# optional — pin to one tenant instead of the multi-tenant default:
# export EXCHANGE_AI_AUTHORITY="https://login.microsoftonline.com/<tenant-id>"
# optional — override the auto-detected timezone (default: /etc/localtime, else UTC):
# export EXCHANGE_AI_TIMEZONE="Asia/Bangkok"EXCHANGE_AI_CLIENT_ID is required; the other two are optional.
Edit (on macOS) ~/Library/Application Support/Claude/claude_desktop_config.json
and add an exchange-ai server under mcpServers. The uvx form needs no clone
or venv — it fetches exchange-ai-connector from PyPI and runs it:
{
"mcpServers": {
"exchange-ai": {
"command": "/opt/homebrew/bin/uvx",
"args": ["exchange-ai-connector"],
"env": {
"EXCHANGE_AI_CLIENT_ID": "<your-app-client-id>",
"EXCHANGE_AI_TIMEZONE": "Asia/Bangkok"
}
}
}
}Use the absolute path to
uvx(which uvx— e.g./opt/homebrew/bin/uvxon Apple-Silicon Homebrew). Claude Desktop is a GUI app and does not inherit your shell'sPATH, so a bare"uvx"won't be found.
Useful variants for the args:
Pin a version (reproducible; uses uv's cache without re-resolving — handy if
your network can't always reach PyPI): ["exchange-ai-connector@0.2.0"]
Run an unreleased version from GitHub:
["--from", "git+https://github.com/wteja/exchange-ai-connector", "exchange-ai-connector"]
If you installed from source into a venv instead, point command at the
binary's absolute path (same PATH reason as above):
"command": "/ABSOLUTE/PATH/TO/.venv/bin/exchange-ai-connector".mcp.json)For Claude Code, put the same server under mcpServers in a .mcp.json at your
project root (Claude Code expands ${VAR} from your environment):
{
"mcpServers": {
"exchange-ai": {
"command": "uvx",
"args": ["exchange-ai-connector"],
"env": {
"EXCHANGE_AI_CLIENT_ID": "${EXCHANGE_AI_CLIENT_ID}",
"EXCHANGE_AI_TIMEZONE": "Asia/Bangkok"
}
}
}
}EXCHANGE_AI_TIMEZONE is optional — omit it to auto-detect from the system
(/etc/localtime, falling back to UTC). command can be a bare uvx here
because Claude Code runs from your shell and inherits its PATH (unlike the
Claude Desktop GUI, which needs the absolute path).
Then fully quit Claude Desktop (Cmd+Q) and reopen it. The exchange-ai
server and its tools should appear in the tools/connector list.
On the first tool call a browser opens for sign-in and consent; the token is cached in your OS keychain and refreshed silently afterward.
Suggested approvals: allow the read-only tools (list_emails, read_email,
read_thread, list_events, read_event, check_availability) to run without
asking, but leave send_email and create_event on ask every time — that's
the human-in-the-loop gate doing its job.
exchange-ai-connectorIt's a stdio MCP server, so it waits silently for a client to connect — there's no interactive output. This is mainly useful for confirming it starts.
Once it's wired into Claude Desktop, drive it in plain language. Examples:
Reading email
"List my latest 10 emails."
"Show me unread emails from this week."
"Read the full email from Alice about the invoice."
"Show me the whole thread for that conversation."
Sending email (gated — you'll approve the draft)
"Reply to Alice's email saying I'll have the report by Friday."
"Send an email to bob@example.com, subject 'Lunch?', asking if he's free Thursday."
"Forward the invoice email to accounting@example.com with a short note."
Reading the calendar
"What's on my calendar this week?"
"Read the details of my 2pm meeting tomorrow."
"Am I free tomorrow 2–3pm?" (work/school accounts only)
"When are alice@contoso.com and I both free Thursday afternoon?" (work/school only)
Creating events (gated — you'll approve the details)
"Create a 30-minute event tomorrow at 2pm titled 'Project sync'."
"Schedule a 1-hour meeting Friday 10am called 'Design review', invite alice@contoso.com and bob@contoso.com."
"Block 9–11am Monday for focus time."
For the gated actions, Claude Desktop shows the exact send_email(...) /
create_event(...) arguments and waits for your Approve / Deny. Want a
change? Tell the agent ("make it 45 minutes", "cc my manager") and it re-proposes.
Every gated action appends one JSON line to
~/.exchange-ai-connector/audit.log:
Sends: {ts, to, subject[, reply_to_id]}
Events: {ts, kind:"event", subject, start[, attendees]}
Append-only JSONL, grep-able:
grep '"kind": "event"' ~/.exchange-ai-connector/audit.logThe OAuth token is cached in your OS keychain (service
exchange-ai-connector, account msal-token-cache) and refreshed silently. The
cached token only carries the scopes you consented to. If you add a scope
(e.g. enabling calendar after email-only), clear the cache so the next run
re-prompts the browser with the new scopes:
python -c "import keyring; keyring.delete_password('exchange-ai-connector','msal-token-cache')"("Not found" just means there was no cache to clear.) Then restart your client.
v1: email — list/read/thread + gated send.
v2 (this release): calendar — list/read events, free/busy availability,
and gated create_event.
A standalone web approval UI, app-only auth, and multi-account approval remain
deliberately out of scope; see the design specs under docs/superpowers/specs/.
Free/busy over a window. Times are naive local, e.g. '2026-07-02T14:00:00'. attendees defaults to just you. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| interval | No | ||
| attendees | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'Read-only' is redundant. However, it adds useful behavioral details like time format and default attendees, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each serving a purpose: purpose, time format, defaults. No fluff, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple, has an output schema (not shown but present), and operates in a calendar context, the description covers essential aspects. It could include more guidance on when to check availability, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by clarifying time format for start/end and default behavior for attendees. The interval parameter is not explained, but overall the description adds significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Free/busy over a window,' which specifies the verb (check availability) and the resource (free/busy info). It distinguishes from sibling tools like list_events and read_event by focusing on availability, not on event details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on time format ('naive local') and default attendees ('just you'), but it does not explicitly state when to use this tool versus alternatives like check_availability before create_event. The read-only hint is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a calendar event; emails invites to attendees. Times are naive local, e.g. '2026-07-02T14:00:00'. IRREVERSIBLE — the client must confirm before allowing.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| body | No | ||
| start | Yes | ||
| subject | Yes | ||
| location | No | ||
| attendees | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral details beyond annotations: it sends email invites, uses naive local time format, and declares irreversibility. This is consistent with the readonlyHint=false and destructiveHint=true annotations, and provides valuable context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the primary function, the second adds critical format and warning. Every word is necessary, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and lack of output schema, the description adequately covers the irreversible action and the time format. However, it does not mention return value (e.g., event ID) or any prerequisites (e.g., calendar must exist). Slightly incomplete, but sufficient for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only adds meaning for the time format (naive local, example value). The parameter names (subject, start, end, body, location, attendees) are self-explanatory, but the description does not elaborate on their purpose or constraints beyond the one hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'calendar event', and distinguishes it from sibling tools like list_events, read_event, and check_availability by specifying that it also sends email invites to attendees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says times are naive local with an example format, and warns that the action is irreversible and requires client confirmation. It provides clear usage context but does not explicitly list alternatives or when not to use this tool beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List messages in a mail folder. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| query | No | ||
| folder | No | inbox |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and description confirms 'Read-only'. However, no additional behavioral traits like pagination, default order, or that it returns summaries not full content are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with purpose and safety trait.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having output schema, description lacks parameter context for 3 parameters. No mention of query syntax, folder usage, or top limits. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. Description does not explain what 'top', 'query', or 'folder' mean or how they affect the result. Fails to add meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List messages in a mail folder' with verb 'list' and resource 'messages'. Read-only qualifier distinguishes from mutation siblings like send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 read_email (single message) or check_availability. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming calendar events, soonest first. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; the description merely repeats 'Read-only' without additional behavioral context such as time horizon or absence of events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loading the action and ordering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list operation given output schema exists, but fails to clarify the scope of 'upcoming' or the meaning of the 'top' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'top' parameter, leaving its meaning and default behavior undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (calendar events), and ordering (soonest first), effectively differentiating it from mutation tools like create_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'read-only' but does not explicitly guide when to use list_events over alternatives like read_event or check_availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one message in full. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds 'Read-only' (redundant) and 'in full' implying complete content, but doesn't specify what 'full' includes (e.g., attachments, headers).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences with no filler, but could be expanded to include more useful information without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return value (e.g., fields like subject, body, sender) and error conditions. With no output schema, description should cover these for a complete read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description provides no additional meaning for the 'message_id' parameter beyond its type, such as format or expected ID structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Read' and resource 'one message in full'. Distinguishes from siblings like 'list_emails' (summaries) and 'read_thread' (thread).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' for previewing or 'read_thread' for threaded view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one calendar event in full. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats 'Read-only' which is already provided by the readOnlyHint annotation, adding no new behavioral insight beyond what annotations already supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise but lacks necessary detail. It is not overly verbose but sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and zero schema coverage, the description fails to explain what 'in full' means regarding returned fields or how to obtain the event_id, making it insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description offers no explanation of the event_id parameter, such as its format or source, leaving the agent without needed context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'one calendar event in full', distinguishing it from siblings like list_events (list multiple) and read_email (read email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 check_availability or list_events. The description lacks context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all messages in a conversation, oldest first. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'read-only' is redundant. It adds 'oldest first' ordering, which is useful. However, no disclosure of pagination, message count limits, or format details is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is front-loaded with the main action. However, it could be expanded to include parameter guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 required param, no enums) and existence of an output schema, the description should at least define the parameter. The lack of parameter description makes it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'conversation_id' has 0% schema description coverage, and the tool description does not explain its purpose or expected format. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads all messages in a conversation in chronological order. It distinguishes from siblings like 'list_emails' (which lists threads) and 'read_email' (single email) by mentioning 'conversation', but does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'read_email' or 'list_emails'. For example, it doesn't clarify that this tool fetches the full thread content while 'list_emails' might only return metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send or reply to an email. IRREVERSIBLE — the client must confirm before allowing.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | Yes | ||
| body | Yes | ||
| subject | Yes | ||
| reply_to_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; the description adds 'IRREVERSIBLE' and client confirmation requirement, providing behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: first states the action, second provides critical caution. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 parameters and no output schema, the description is minimal. Missing details on how to reply (reply_to_id), use cc, or format the body. The irreversible warning is good but incomplete for a sending tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameters are documented in the description. The description fails to add any meaning to the five parameters (to, subject, body, cc, reply_to_id), which severely limits agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Send or reply to an email,' which is specific and distinct from sibling tools like read_email or list_emails. The description differentiates the tool's action well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns 'IRREVERSIBLE' and requires client confirmation, providing clear usage guidance. However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0check_availabilitycreate_eventlist_emailslist_eventsread_emailread_eventread_threadsend_emailScored across 8 tools
Each tool targets a distinct operation within either the calendar or email domain, with no overlapping purposes. check_availability, create_event, list_events, and read_event are clearly separate; similarly for email tools.
All tools follow a consistent verb_noun pattern using snake_case (e.g., check_availability, list_emails). No mixing of conventions or ambiguous verbs.
With 8 tools covering both email and calendar operations, the count is well-scoped for the connector's purpose. Each tool serves a clear function without superfluous entries.
The tool surface covers essential read and create operations but lacks update and delete for calendar events, and email deletion or folder management. These are notable gaps for a full lifecycle.
Email inboxes and calendars for AI agents: send, receive, search, draft and schedule.
Email inboxes and calendars for AI agents: send, receive, search, draft and schedule.
Permissioned access to Outlook, OneDrive and Teams via the user's own Microsoft account
Give your agent its own email address with graduated human oversight, from approval to autonomy.
