What can you do with this server?

This MCP server provides comprehensive access to on-premises Microsoft Exchange via EWS for managing email, calendar, contacts, folders, and availability data. * Email: List, search, read, send, reply, forward, move, copy, delete, and mark emails; create and send drafts; download attachments. * Folders: List and create mailbox folders. * Calendar: List, get, create, update, and delete events; respond to meeting invites; find free time slots; get personal availability; list calendars. * Contacts: Search (personal and GAL), get, create, update, and delete contacts. * System: Test connectivity (ping) and retrieve mailbox metadata.

Which integrations are available for this server?

The server is distributed as a PyPI package named outlook-ews-mcp.

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 find my unread emails from last week" 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.

de en es ja ko ru zh

outlook-mcp

by viartemev

Overview Schema Source Related Servers Discussions Admin

Python

Remote

outlook-ews-mcp

Python MCP Exchange Status License

outlook-ews-mcp is an MCP server for on-prem Microsoft Exchange via EWS (exchangelib). It gives MCP-compatible clients (Claude Desktop, Claude Code, and any other MCP client) access to email, calendar, contacts, folders, attachments, and availability data through a single, testable Python service — no direct mailbox scripting required.

Renamed from outlook-mcp. That name was already taken on PyPI by an unrelated project, so the distribution and CLI name are now outlook-ews-mcp. The Python import path is unchanged. Until the first tagged PyPI release, install from this repository as shown below.

Related MCP server: owa-mail-mcp

Highlights

Email — list, search (substring or Advanced Query Syntax), read, send, reply, forward, move, copy, delete, mark, categorize, bulk actions, raw MIME export, attachment add/delete
System — Inbox Rules, Out-of-Office (automatic replies), read-only delegate listing
Calendar — list, create, update, delete, respond to invites, find free slots, view a shared/delegate mailbox's calendar, Room Finder, bulk actions
Contacts — search, read, create, update, delete
Folders & attachments — folder CRUD and attachment download
Auth — NTLM and Basic against on-prem Exchange
Transport — stdio and SSE
Architecture — centralized error mapping through a single ExchangeClient abstraction (see Project notes)
Safety — a privacy-safer smoke check by default (see Smoke check)
Ops — Docker image plus GitHub and GitLab CI/CD pipelines included

Tool catalog

Every tool below is registered in tool_specs.py, the single source of truth for its name, description, and schema. Read-only marks tools that never modify the mailbox — they get more concurrency (see Request queue) and are safe to call speculatively.

System

Tool	Description	Read-only
`ping_exchange`	Check connectivity to Exchange	✅
`get_mailbox_info`	Get mailbox metadata	✅
`list_delegates`	List mailbox delegates and their folder permission levels — read-only because `exchangelib` has no delegate write support	✅
`list_inbox_rules`	List server-side inbox rules	✅
`create_inbox_rule`	Create a server-side inbox rule, e.g. "from this sender → move to folder"
`update_inbox_rule`	Enable/disable a rule or change its priority (other fields aren't updatable here)
`delete_inbox_rule`	Delete a server-side inbox rule by id
`get_out_of_office`	Get the out-of-office (automatic reply) settings	✅
`set_out_of_office`	Turn automatic replies off, on, or schedule a start/end window

⚠️ create_inbox_rule / update_inbox_rule / delete_inbox_rule manage rules over EWS, which removes the client-side rule blob desktop Outlook keeps — this can wipe rules a user created in Outlook itself. This is documented EWS behavior, not a bug here.

Email

Tool	Description	Read-only
`list_emails`	List emails in a folder	✅
`get_email`	Get a full email by id	✅
`get_email_mime`	Export a message's raw RFC 822 MIME content, base64-encoded	✅
`get_thread`	Get every message of a conversation in order, bodies included	✅
`search_emails`	Search by substring (subject/body/sender) or server-side Advanced Query Syntax	✅
`send_email`	Send a new email
`reply_email`	Reply to an email
`forward_email`	Forward an email
`move_email`	Move an email to another folder
`copy_email`	Copy an email to another folder
`move_emails`	Bulk move, with per-item results — one bad id doesn't fail the rest
`copy_emails`	Bulk copy, with per-item results
`delete_emails`	Bulk delete, with per-item results (soft-deletes unless `hard_delete`)
`delete_email`	Delete an email
`mark_email`	Update read state, importance, or the follow-up flag
`categorize_email`	Set, add, or remove Outlook categories (the coloured labels)
`mark_emails`	Bulk version of `mark_email`, with per-item results
`categorize_emails`	Bulk version of `categorize_email`, with per-item results
`list_categories`	List categories in use with counts, sampled from recent messages (not the mailbox master category list)	✅
`list_folders`	List mailbox folders	✅
`create_folder`	Create a mailbox folder
`rename_folder`	Rename a folder — refuses built-in folders (Inbox, Sent Items, Calendar, ...)
`delete_folder`	Delete a folder and everything in it — refuses built-in folders
`create_draft`	Create an email draft
`update_draft`	Update a draft; omitted fields are left unchanged, `attachments` (if given) replaces the whole set
`send_draft`	Send an existing draft
`add_attachment`	Attach a local file to a message, typically a draft — the file must live under `EXCHANGE_ATTACHMENT_ROOT`
`delete_attachment`	Remove one attachment from a message by id
`get_attachment`	Save an attachment to disk	✅

Calendar

Tool	Description	Read-only
`list_events`	List calendar events in a time range; pass `mailbox` for a colleague's default calendar (needs delegate/impersonation access, not combinable with `calendar_id`)	✅
`get_event`	Get a calendar event by id; pass `mailbox` for a colleague's calendar	✅
`create_event`	Create a calendar event
`update_event`	Update a calendar event
`delete_event`	Delete a calendar event
`respond_to_invite`	Accept, decline, or tentatively respond to an invite
`find_free_slots`	Find open meeting time slots	✅
`delete_events`	Bulk delete events, with per-item results
`respond_to_invites`	Bulk respond to invites, with per-item results
`get_my_availability`	Get free/busy slots; pass `mailbox` for a colleague's calendar	✅
`list_calendars`	List calendars	✅
`list_room_lists`	List Room Finder room lists (groups of meeting rooms)	✅
`list_rooms`	List the meeting rooms in a Room Finder room list	✅

Contacts

Tool	Description	Read-only
`search_contacts`	Search contacts	✅
`get_contact`	Get a contact by id	✅
`create_contact`	Create a personal contact
`update_contact`	Update a personal contact
`delete_contact`	Delete a personal contact

Typical use cases

Connect Claude Desktop or another MCP client to on-prem Exchange
Search inbox messages and fetch full email content
Send or draft emails from AI workflows
Inspect calendars and create meetings
Check free/busy windows for scheduling
Search personal contacts or the Global Address List
Expose Exchange operations through a controlled MCP boundary instead of direct mailbox scripting

Security notes

What the current code does:


Scoped connectivity	Connects only to the Exchange/EWS endpoint configured in `EXCHANGE_SERVER`
No telemetry	Contains no telemetry, analytics, or third-party data export logic
Secrets stay local	Keeps secrets in environment variables / `.env`, ignored by `.gitignore` (`.env`, `.env.*`, while keeping `.env.example`)
Clean error payloads	Structured MCP error responses never include raw Exchange exception text, message bodies, attachment contents, or passwords; successful tools return only the mailbox data they were asked for
Clean logs	`LOG_LEVEL` only controls the app's own `outlook_mcp.*` loggers; `exchangelib`'s SOAP XML loggers — which would otherwise dump full request/response XML, even at `ERROR` level on transport errors — are always force-silenced
Clean Docker builds	`.dockerignore` excludes `.env`, tests, caches, and VCS metadata from the build context

What you should still be careful with:

EXCHANGE_VERIFY_SSL=false disables TLS certificate verification — trusted internal/self-signed environments only.
EXCHANGE_AUTH_TYPE=Basic sends credentials in the clear, so the server refuses to start against an http:// EXCHANGE_SERVER; only override with EXCHANGE_ALLOW_INSECURE_BASIC_AUTH=true for a local/test server you control.
get_attachment writes files to disk, and send_email/reply_email/forward_email/ create_draft read local files (via attachments) and attach their contents to outgoing mail. Combined with untrusted email content, this is a plausible path for prompt-injected exfiltration of any file readable by the process. Local file access is refused by default and only works once EXCHANGE_ATTACHMENT_ROOT is set to an absolute directory, which then confines both attachments paths and get_attachment's save_path to that directory tree (an unset save_path still falls back to the system temp directory).
outlook-ews-mcp-smoke is privacy-safe by default and prints only masked mailbox info plus counts; set OUTLOOK_MCP_SMOKE_INCLUDE_DATA=true only if you explicitly want real inbox/event data in stdout.
If you enable file logging with LOG_FILE, protect that file with OS permissions.
If you publish Docker images from CI, protect GitLab/GitHub project access and registry permissions.

Quick start

uv venv
source .venv/bin/activate
uv pip install -e .[dev]
cp .env.example .env
outlook-ews-mcp

By default the server runs in stdio mode. Set MCP_TRANSPORT=sse to start an HTTP server instead.

Configuration

Minimal .env to get started — everything else below has a working default:

EXCHANGE_SERVER=https://mail.company.com/EWS/Exchange.asmx
EXCHANGE_USERNAME=DOMAIN\username
EXCHANGE_PASSWORD=secret
EXCHANGE_EMAIL_ADDRESS=user@company.com
EXCHANGE_AUTH_TYPE=NTLM

A fully commented copy of every variable lives in .env.example.

Variable	Default	Description
`EXCHANGE_SERVER`	(required)	EWS endpoint URL, e.g. `https://mail.company.com/EWS/Exchange.asmx`
`EXCHANGE_USERNAME`	(required)	`DOMAIN\username` or a UPN. Exactly one backslash — dotenv does not process escape sequences
`EXCHANGE_PASSWORD`	(required)	Account password
`EXCHANGE_EMAIL_ADDRESS`	unset	SMTP address; set when `EXCHANGE_USERNAME` isn't one
`EXCHANGE_AUTH_TYPE`	`NTLM`	`NTLM` or `Basic`
`EXCHANGE_ALLOW_INSECURE_BASIC_AUTH`	`false`	Allow `Basic` auth over `http://` — local/test servers only
`EXCHANGE_VERIFY_SSL`	`true`	Verify the server's TLS certificate; `false` only for trusted internal/self-signed setups
`EXCHANGE_VERSION`	unset (auto-detected)	Exchange server version, e.g. `EXCHANGE_2016`
`EXCHANGE_TIMEZONE_FALLBACK`	`Europe/Moscow`	Used only when Exchange reports an unresolvable GUID timezone id; normal operations use the mailbox's own default timezone
`EXCHANGE_TIMEOUT`	`30`	Per-request timeout in seconds (1–300)
`EXCHANGE_MAX_RETRY_WAIT_SECONDS`	`90`	Wall-clock retry budget for read-only calls when Exchange reports itself busy, not a retry count; `0` disables retries. Writes are never auto-retried
`EXCHANGE_IMPERSONATE_AS`	unset	Mailbox to impersonate (requires Exchange impersonation permissions)
`EXCHANGE_ATTACHMENT_MAX_SIZE_MB`	`10`	Max size per attachment, enforced on both upload and `get_attachment` download (1–100)
`EXCHANGE_ATTACHMENT_MAX_COUNT`	`10`	Max attachments on a single send/reply/forward/create_draft call (1–100)
`EXCHANGE_ATTACHMENT_MAX_TOTAL_SIZE_MB`	`25`	Max combined attachment size on a single call (1–500)
`EXCHANGE_ATTACHMENT_ROOT`	unset (disabled)	Directory that confines attachment paths. Unset refuses all local file access for `attachments`/`save_path`; set to an absolute directory to allow paths inside it
`EXCHANGE_EMAIL_BODY_MAX_CHARS`	`200000`	Cap on `get_email`'s `body_text`/`body_html` (1,000–5,000,000); longer bodies are truncated with `truncated: true`
`EXCHANGE_EMAIL_MIME_MAX_SIZE_MB`	`25`	Cap on raw MIME export size before base64 expansion (1–100)
`EXCHANGE_SIGNATURE_TEXT`	unset	Appended to outgoing text bodies and replies/forwards. No EWS signature API exists, so this is configuration, not the mailbox's Outlook signature
`EXCHANGE_SIGNATURE_HTML`	unset	Appended to outgoing HTML bodies. Same caveat as above; no cross-conversion between the two. Either can be skipped per call with `include_signature: false`
`MCP_TRANSPORT`	`stdio`	`stdio` or `sse`
`MCP_SSE_HOST`	`127.0.0.1`	Bind host when `MCP_TRANSPORT=sse`
`MCP_SSE_PORT`	`8080`	Bind port when `MCP_TRANSPORT=sse`
`MCP_MAX_CONCURRENCY`	`4`	Concurrent read-only tool calls (1–8); mutating calls always run exclusively. See Request queue
`MCP_MAX_QUEUE_SIZE`	`20`	Max calls admitted at once, running + waiting (1–1000); beyond that, calls get an immediate `server_busy` error
`LOG_LEVEL`	`INFO`	`DEBUG`, `INFO`, `WARNING`, or `ERROR`
`LOG_FILE`	unset (stderr)	Log file path; protect it with OS permissions if set

Behavior notes that aren't tied to a single variable:

list_events and find_free_slots accept a bounded limit (default 200, maximum 1000); event ranges are capped at 366 days and free-slot ranges at 31 days, so broad queries can't produce unbounded EWS or MCP responses.
Listings stay lean by design: email summaries carry the sender but not recipient lists (get_email has them), list_events returns events without bodies (get_event has them), and get_email returns RFC-822 headers only with include_headers: true.
Send operations return id: null when EWS doesn't provide a durable id for the sent copy (notably replies, forwards, and sent drafts).
Attachment metadata includes downloadable; embedded Exchange item attachments have downloadable: false and can't be saved by get_attachment.

Request queue

Clients issue several tool calls in parallel. Exchange work is blocking, so the server runs it in worker threads and admits calls through one shared FIFO queue.

MCP_MAX_CONCURRENCY (default 4) sets how many read-only calls run at once, so an agent asking for an email, the folder list, and the calendar pays the slowest round trip instead of the sum. Mutating calls always run exclusively — one at a time, never overlapping a read — so read/write races on shared account state can't happen. Callers beyond the limit wait their turn, served in arrival order; a waiting mutation blocks later reads from overtaking it.
MCP_MAX_QUEUE_SIZE (default 20) caps how many calls can be admitted at once, running or waiting. Once that many are already in, further calls get an immediate server_busy error instead of joining an unbounded queue.
The transport stays responsive while work is in flight. Tools are awaited rather than run on the event loop thread, so finished responses go out immediately and pings are answered while a long call is still running.
There is no per-call timeout, deliberately. A thread blocked on a socket read can't be killed from outside; the runtime can only stop waiting for it, which abandons the thread along with the EWS session it holds. exchangelib's session pool has a hard maximum and hands out sessions in a loop with no give-up path, so leaked sessions eventually starve it and every later call blocks forever. A slow call is waited out instead, bounded by EXCHANGE_TIMEOUT plus EXCHANGE_MAX_RETRY_WAIT_SECONDS: the account's retry policy is fail-fast, so every EWS call raises on its first transient error rather than exchangelib retrying it forever internally, and ExchangeClient retries only read-only calls itself, bounded by that wall-clock budget. Writes are never auto-retried. Overruns past the expected budget are logged.

Claude Desktop example

{
  "mcpServers": {
    "outlook": {
      "command": "outlook-ews-mcp",
      "env": {
        "EXCHANGE_SERVER": "https://mail.company.com/EWS/Exchange.asmx",
        "EXCHANGE_USERNAME": "DOMAIN\\username",
        "EXCHANGE_PASSWORD": "secret",
        "EXCHANGE_EMAIL_ADDRESS": "user@company.com",
        "EXCHANGE_AUTH_TYPE": "NTLM"
      }
    }
  }
}

Smoke check

After filling in .env, run:

outlook-ews-mcp-smoke

Default output is sanitized for safer verification. If you intentionally want sample mailbox/event data in the output:

OUTLOOK_MCP_SMOKE_INCLUDE_DATA=true outlook-ews-mcp-smoke

Docker

docker build -t outlook-ews-mcp .
docker run --rm --env-file .env outlook-ews-mcp

CI/CD

GitHub Actions and GitLab CI both run lint, formatting, type checks, tests, dependency audit, and package builds, using the uv version pinned in pyproject.toml.


GitHub	Additionally publishes tagged releases (`v*`) to PyPI via OIDC trusted publishing. Before the first release, configure a PyPI pending publisher for repository `viartemev/outlook-ews-mcp`, workflow `ci.yml`, and environment `pypi` — no long-lived PyPI token is stored in GitHub.
GitLab	Additionally builds and pushes a Docker image to the GitLab Container Registry on the default branch and on tags, using the built-in `CI_REGISTRY` / `CI_REGISTRY_USER` / `CI_REGISTRY_PASSWORD` / `CI_REGISTRY_IMAGE` variables.

Default image tagging behavior:

Trigger	Tags pushed
Default branch	`:$CI_COMMIT_SHORT_SHA` and `:latest`
Git tag	`:$CI_COMMIT_TAG`

Development

uv run --python 3.12 --with '.[dev]' ruff check .
uv run --python 3.12 --with '.[dev]' pytest -q

Project notes

The implementation is centered around a single ExchangeClient abstraction so auth, transport, retries, and error mapping stay centralized.
Errors are returned in a structured JSON form suitable for MCP isError=true handling.

Contributing

Bug reports and PRs are welcome — see CONTRIBUTING.md for how to set up a dev environment and run the test suite without a real Exchange server. For vulnerability reports, see SECURITY.md.

License

MIT — see LICENSE.

Available Tools

31 tools

copy_emailC

Copy email to another folder

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It only states the basic function without disclosing side effects, permissions, error conditions, or output behavior.

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

Conciseness2/5

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

The description is extremely short (6 words), but this conciseness sacrifices critical information. It is not a model of efficient communication since it omits necessary details.

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?

Given a single undocumented parameter and no annotations, the description fails to provide enough context for correct invocation. The output schema exists but is not leveraged in the description.

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

Parameters1/5

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

The only parameter 'kwargs' is completely undocumented in both schema and description, with 0% schema description coverage. The description offers no guidance on required keys or values.

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 the action ('copy') and the resource ('email to another folder'), distinguishing it from sibling tools like 'move_email' which implies relocation rather than duplication.

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 (e.g., copy vs. move email). No prerequisites or context provided, leaving the agent to infer usage.

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

create_contactC

Create a personal contact

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are present, and the description provides no behavioral details such as authentication requirements, side effects, or error handling. The description is too sparse to be informative.

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

Conciseness2/5

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

The description is minimal (one sentence) but lacks necessary detail. While concise, it fails to provide useful information beyond the tool's name, reducing its effectiveness.

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

Completeness1/5

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

Given the low parameter count, the description should still explain the parameter's structure and expected output. It does not, leaving the agent with no actionable information.

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

Parameters1/5

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

The sole parameter 'kwargs' is opaque with no description or type constraints. With 0% schema description coverage, the description offers no clarification, making it impossible for an agent to know what keys or values are expected.

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 the verb 'Create' and the resource 'personal contact'. It distinguishes from sibling tools like 'update_contact' and 'delete_contact', though it does not elaborate on what constitutes a personal contact.

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. No exclusions, prerequisites, or contextual advice provided.

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

create_draftC

Create an email draft

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, and the description fails to disclose behavioral traits beyond the basic action. It does not mention what the draft entails (e.g., recipients, body) or any side effects, leaving the agent uninformed about critical behavior.

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. However, it is too brief to be useful, scoring an average as the brevity comes at the cost of essential information.

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 (not detailed) and a complex domain (email drafts), the description provides no information on return values, how to populate content, or relation to other email tool actions, making it incomplete for effective use.

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

Parameters1/5

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

The input schema has a single required 'kwargs' parameter with no defined properties and 0% coverage. The description adds no explanation, so the agent cannot understand how to structure the parameter or what keys are expected, making it nearly unusable.

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 the action ('Create') and resource ('email draft'), which is specific. However, given sibling tools like 'send_draft' and 'create_event', it does not differentiate further, but it is still unambiguous.

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 is provided on when to use this tool versus alternatives such as 'send_draft' or 'create_event'. The description lacks context for appropriate usage scenarios.

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

create_eventC

Create a calendar event

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, and the description only says 'Create a calendar event'. It does not disclose any behavioral traits such as permissions required, side effects, or what happens if the event already exists.

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

Conciseness2/5

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

The description is a single sentence, but it is under-specified. Conciseness is achieved at the cost of omitting essential information.

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?

For a tool with no annotations, generic parameter, and no explanation of output, the description is insufficient. The agent needs more context to use it correctly.

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

Parameters1/5

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

The input schema has a single parameter 'kwargs' with no description and 0% schema coverage. The description adds no context about what kwargs should contain, leaving the agent without guidance.

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?

Description states 'Create a calendar event', clearly indicating the action (create) and resource (calendar event). However, it does not distinguish from sibling tools like update_event or respond_to_invite, but the verb 'create' is unambiguous.

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 update_event or respond_to_invite. No prerequisites or usage constraints provided.

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

create_folderC

Create a mailbox folder

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

The description gives no behavioral details beyond the action. Since no annotations are present, the description should disclose effects (e.g., duplication behavior, permissions, limits), but it does not. This is a significant gap.

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

Conciseness2/5

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

The description is very short (4 words), but it is under-specification rather than concise. It sacrifices necessary detail for brevity.

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

Completeness1/5

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

With 0% schema description coverage and no annotations, the description must provide comprehensive context. It fails to explain the 'kwargs' parameter, return value (though output schema exists), or any usage details. Completely inadequate for the tool's complexity.

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

Parameters1/5

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

The sole parameter 'kwargs' is not described in the schema or description. The description adds no meaning to what this parameter should contain, making it impossible for an AI agent to use correctly.

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 states 'Create a mailbox folder', which clearly identifies the action (create) and resource (mailbox folder). It distinguishes from sibling tools like 'list_folders' or 'move_email' by specifying creation. However, it lacks specificity about which mailbox or folder hierarchy.

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 'list_folders' for reading or other creation tools. No context on prerequisites or exclusions is provided.

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

delete_contactC

Delete a personal contact

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, so the description must disclose behavioral traits. It only states 'Delete', which implies destruction, but lacks details on permanence, authorization, 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 at the expense of essential details. It could be restructured to include parameter expectations within the same brevity.

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

Completeness1/5

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

Given the vague input schema, lack of annotations, and many sibling tools, the description fails to provide enough context for correct invocation. The agent is left with critical knowledge gaps.

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

Parameters1/5

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

The input schema has a single 'kwargs' parameter with 0% description coverage. The description offers no guidance on what kwargs should contain, leaving the agent unable to construct a valid input.

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 the action 'Delete' and the resource 'personal contact', effectively distinguishing it from sibling tools like create_contact, update_contact, and get_contact.

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. With 30 sibling tools including delete_email and delete_event, the description should clarify its specific scope.

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

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior1/5

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

Without annotations, the description carries full burden for behavioral disclosure. It does not specify whether deletion is permanent, moves to trash, or if any confirmation 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.

Conciseness2/5

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

The description is extremely short and under-specified. While front-loaded, it fails to provide essential details, making it insufficiently concise.

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?

Given that an output schema exists but no annotations, the description is incomplete. It does not cover key contextual details like deletion behavior or side effects.

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

Parameters1/5

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

The sole parameter 'kwargs' has no description in the schema (0% coverage), and the description adds no meaning beyond the parameter 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 clearly states the verb 'Delete' and resource 'an email', which is specific and distinguishes it from sibling tools like 'delete_contact' or 'delete_event'.

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 is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description gives no context for appropriate usage.

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

delete_eventC

Delete a calendar event

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states it deletes an event. Missing critical details such as irreversibility, required permissions, impact on recurring events, or cancellation notifications.

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 very concise (one sentence), but it sacrifices necessary detail. While it states the purpose, it does not earn its place by providing additional value beyond the name.

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?

Given the number of sibling tools and the generic parameter, the description is insufficient. It does not explain how to use the output schema or how to identify the event, leaving the agent with incomplete guidance.

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

Parameters1/5

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

The only parameter is 'kwargs' with no description or sub-properties. The schema coverage is 0%, and the description adds no meaning to this parameter, leaving the agent without guidance on how to specify the event to delete.

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 the verb 'delete' and the resource 'calendar event', distinguishing it from sibling tools like delete_contact or delete_email. However, it could be more specific by indicating how the event is identified.

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 is provided on when to use this tool versus alternatives (e.g., respond_to_invite for meeting responses). There is no mention of prerequisites or when not to use it.

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

find_free_slotsD

Find meeting time slots

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.5/5.0

Behavior1/5

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

With no annotations, the description must disclose behavioral traits, but it omits whether the tool is read-only, mutating, requires authentication, or has side effects. The agent has zero insight into behavior.

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

Conciseness2/5

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

The description is short but severely under-specified. Brevity is wasted without essential details; it does not earn its place by being informative.

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

Completeness1/5

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

Given no annotations, a meaningless input schema, and no explanation of output (though an output schema exists), the description is completely inadequate for a tool with many siblings and potential complexity.

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

Parameters1/5

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

The input schema has a single 'kwargs' parameter with no type or description, and schema description coverage is 0%. The description adds no parameter meaning, leaving the agent blind to required inputs.

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

Purpose2/5

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

The description 'Find meeting time slots' is vague and barely extends the tool name. It doesn't specify what inputs are needed (e.g., attendees, date ranges) or output format, and fails to distinguish it from sibling tools like 'get_my_availability'.

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 is given on when to use this tool versus alternatives. Sibling tools like 'get_my_availability' and 'list_events' likely overlap, but the description offers no comparative context.

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

forward_emailC

Forward an email

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are present, so the description must convey behavioral traits. It does not disclose whether forwarding creates a draft or sends immediately, required permissions, 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.

Conciseness2/5

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

While short, the description is too terse and lacks substance. It fails to earn its place as it provides no actionable information beyond the tool name.

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

Completeness1/5

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

Given the complexity of email forwarding and the lack of schema detail, the description is severely incomplete. It does not address recipient, body, or attachments, leaving critical gaps.

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

Parameters1/5

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

The input schema has a single 'kwargs' parameter with 0% description coverage. The description offers no details on what kwargs should contain, leaving the agent with no guidance.

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 'Forward an email' clearly states the verb and resource, distinguishing it from siblings like reply_email and send_email. However, it is terse and lacks specificity about the forwarding behavior.

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 is provided on when to use this tool versus alternatives like reply_email or send_draft. There are no exclusions or context for use.

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

get_attachmentC

Save an attachment to disk

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/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. Only mentions 'save to disk' without indicating side effects, permissions, or whether operation is idempotent. Fails to specify if attachment is deleted after save or if it requires authentication.

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?

One sentence, very short, but lacks essential details. It is concise but at the expense of completeness. Could be improved with brief parameter notes.

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

Completeness1/5

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

Despite having an output schema, the description is nearly empty. No mention of how to identify the attachment (e.g., attachment ID), expected input format, or return value. Incomplete for a file saving operation.

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?

Single parameter 'kwargs' is an object with no schema details. Description does not explain what keys or values are needed, leaving the agent without guidance. With 0% schema coverage, this is a critical gap.

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?

Description clearly states the action 'Save an attachment to disk', which is a specific verb-resource combination. However, it doesn't differentiate from sibling tools like get_email, and the name 'get_attachment' suggests retrieval while description implies download.

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, such as get_email or other retrieval tools. No context about prerequisites or conditions.

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

get_contactC

Get a contact by ID

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning read-only nature, error handling, permissions, or side effects. This is insufficient 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.

Conciseness3/5

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

The description is extremely concise at one sentence, but it is underspecified. It lacks critical information that would justify its brevity. Structure is simple but not effective.

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

Completeness2/5

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

Given the vague schema and lack of annotations, the description does not provide enough context. It neither explains the input structure nor the expected output (though an output schema exists). The tool's purpose is clear but operational details are missing.

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% (the 'kwargs' parameter has no described properties). The description says 'by ID' but fails to specify how the ID fits into the input, leaving the agent to guess. The description adds little value beyond the schema.

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

Purpose3/5

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

The description states 'Get a contact by ID', which identifies the verb and resource. However, the input schema only has a generic 'kwargs' object without an explicit ID field, creating a mismatch between the description and the schema. This reduces clarity about how to use the 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 is provided on when to use this tool versus alternatives like search_contacts or get_email. There are no context cues, exclusions, or scenarios mentioned, leaving the agent without decision support.

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

get_emailC

Get a full email by ID

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/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 responsibility. It only states 'get', implying a read operation, but does not disclose any side effects, permissions needed, or response characteristics.

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 very concise at one sentence, front-loading the purpose. However, it sacrifices essential details that could be added without much length.

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?

Given the presence of an output schema, the description need not explain return values, but it lacks parameter details and usage context. The tool is simple, but the description is too minimal even for a low-complexity tool.

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

Parameters1/5

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

The input schema has one parameter 'kwargs' with no description, and the tool description mentions 'by ID' but does not explain how to pass the ID or what kwargs should contain. Schema coverage is 0%, so the description fails to add meaning.

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 states 'Get a full email by ID', which clearly indicates the action (get) and the resource (email) with a distinguishing detail (by ID). It differentiates from sibling tools like list_emails or copy_email that have different purposes.

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 get_attachment or search_emails. No information about prerequisites or when not to use it.

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

get_eventB

Get a calendar event by ID

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, and the description lacks behavioral details such as whether authentication is required, error handling for missing IDs, or read-only nature. The agent gets no transparency beyond the basic purpose.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words. It could be slightly expanded, but it earns its place for a simple get-by-ID operation.

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?

While an output schema exists, the input parameter is poorly defined. The tool is simple, but the missing parameter guidance makes it incomplete for correct invocation.

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

Parameters1/5

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

The input schema has a single 'kwargs' parameter with no description (0% coverage). The description does not explain that kwargs should contain the event ID, leaving the agent uninformed about how to invoke the tool correctly.

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 'Get a calendar event by ID' provides a clear verb ('Get'), resource ('calendar event'), and identifier ('by ID'). It effectively distinguishes this tool from siblings like create_event or update_event.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident from the name and description. The agent can infer usage context.

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

get_mailbox_infoC

Get mailbox metadata

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It does not disclose any behavioral traits such as read-only nature, authentication needs, or side effects beyond implying a read operation.

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

Conciseness2/5

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

The description is extremely short (three words). While brief, it is under-specified and does not provide enough information to be useful, sacrificing completeness for brevity.

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?

Given the presence of a complex opaque parameter (kwargs) and no annotations, the description is incomplete. It fails to explain how to use the tool or what metadata is returned, even though an output schema exists.

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

Parameters1/5

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

The input schema has 0% description coverage, and the description does not explain the single parameter 'kwargs'. It adds no meaning beyond the schema.

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

Purpose4/5

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

The description clearly states 'Get mailbox metadata', which is a specific verb+resource. It distinguishes from sibling tools like get_contact or get_email by focusing on mailbox-level metadata. However, the term 'metadata' is somewhat vague.

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 is provided on when to use this tool versus alternatives like list_folders or get_email. There is no mention of prerequisites, context, or exclusions.

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

get_my_availabilityC

Get free and busy slots

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.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 the full burden. It does not disclose whether the tool is read-only, requires authentication, or has any rate limits. The output schema is present but not described, missing 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.

Conciseness2/5

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

The description is too brief at one sentence, sacrificing necessary detail. It lacks structure and front-loading of critical information like input requirements.

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?

Even with an output schema, the description fails to explain the context of 'free and busy slots'—such as time ranges, how slots are defined, or how the output relates to the input. Incomplete for effective use.

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

Parameters1/5

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

The only parameter 'kwargs' is a generic object with no description, and the schema coverage is 0%. The description adds no meaning beyond the schema, leaving the agent unable to determine what arguments are required.

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 'Get free and busy slots' clearly states the verb 'Get' and the resource 'free and busy slots', indicating what the tool returns. However, it does not differentiate from the sibling tool 'find_free_slots', which likely serves a similar purpose.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'find_free_slots'. There is no mention of prerequisites, time ranges, or context for the slots.

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

list_calendarsC

List calendars

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as pagination, authentication requirements, whether it lists all calendars or only accessible ones, or any side effects. The description carries the full burden and fails completely.

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

Conciseness2/5

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

While the description is extremely concise (two words), it is underspecified and does not provide enough information. Conciseness should not come at the expense of clarity or 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?

Given the tool's simplicity and the existence of an output schema, the description could still provide context such as 'lists all calendars accessible to the user' but does not. The description is incomplete for an agent to understand the tool's functionality.

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

Parameters1/5

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

The input schema has one parameter 'kwargs' with no description (schema coverage 0%), and the description does not add any meaning to this parameter. The agent has no idea what 'kwargs' accepts.

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 'List calendars' clearly states the verb 'List' and resource 'calendars', which is specific and distinguishes it from sibling tools like 'list_emails' or 'list_events' by resource type. However, it does not provide any additional context or differentiation beyond the name.

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?

There is no guidance on when to use this tool, when not to use it, or alternatives. The description is minimal and does not help the agent decide between this and related tools like 'list_events' or 'list_folders'.

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

list_emailsD

List emails in a folder

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.8/5.0

Behavior1/5

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

No annotations exist, and the description does not disclose behavioral traits like authentication requirements, whether the operation is read-only, pagination behavior, or return format. The agent is left uninformed about side effects or constraints.

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

Conciseness2/5

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

At six words, the description is extremely concise, but this brevity sacrifices critical information. It does not earn its place as every sentence should; it is under-specified rather than efficiently informative.

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

Completeness1/5

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

Given the opaque parameter schema, no annotations, many sibling tools, and an existing output schema not described, the description fails to provide enough context for correct invocation. It lacks details on folder identification, filtering, pagination, or output structure.

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

Parameters1/5

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

The only parameter is 'kwargs' of type object, with no schema-level descriptions and 0% coverage. The description fails to explain what keys or values this parameter should contain, leaving the agent without guidance on how to construct the argument.

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

Purpose3/5

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

The description 'List emails in a folder' clearly states the action and resource, but lacks specificity about which folder or what subset of emails (e.g., all, recent, filtered). It does not distinguish from sibling tools like 'search_emails' which also deal with listing emails.

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 is provided on when to use this tool versus alternatives such as 'search_emails', 'get_email', or 'list_folders'. The agent has no context on prerequisites or exclusions.

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

list_eventsC

List calendar events in a time range

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	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 are present, so the description must fully disclose behavior. It only says 'list events in a time range' but omits details like pagination, ordering, event detail level, or whether it returns all properties. This is insufficient for a list operation.

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 with no extraneous words, but it is too terse and lacks necessary details. Conciseness is achieved at the cost 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?

Given the complexity (catch-all parameter, likely output schema present but not described) and lack of annotations, the description is inadequate. It does not explain how to use the tool effectively or what to expect in return.

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

Parameters1/5

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

The input schema defines a single parameter 'kwargs' with 0% description coverage, meaning the schema provides no semantics. The description does not clarify what 'kwargs' accepts or how to specify the time range, leaving the agent with no guidance.

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

Purpose5/5

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

The description clearly states the verb 'list', the resource 'calendar events', and the scope 'in a time range'. It distinguishes from sibling tools like list_calendars (which lists calendars) and get_event (which retrieves a single event).

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 is provided on when to use this tool versus alternatives such as get_event, list_calendars, or find_free_slots. There is no mention of typical use cases or limitations.

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

list_foldersC

List mailbox folders

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided; description only says 'list' implying read-only, but lacks details on pagination, error states, 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.

Conciseness2/5

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

Too brief and under-specified; a single sentence without structure or additional context, missing critical information.

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 fails to explain the tool's behavior or parameter usage, leaving the agent with insufficient information.

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

Parameters1/5

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

The sole parameter 'kwargs' has no description in schema and the description adds no meaning, leaving the agent without any guidance on how to use it.

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 states 'List mailbox folders' with a specific verb and resource, clearly distinguishing from sibling tools like 'create_folder' and 'list_emails'.

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, such as when to use 'create_folder' or 'list_emails' instead.

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

mark_emailC

Update email flags

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior2/5

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

With no annotations, the description carries the burden of behavioral disclosure. It only states 'Update email flags', implying mutation but does not describe safety, permissions, or effects on the email. Minimal value beyond purpose.

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 very concise at one sentence, but it is under-specified. While brevity is appreciated, it lacks structure and important details, making it only minimally acceptable.

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?

Given the opaque input schema and no additional context, the description is incomplete. An output schema exists but does not compensate for the lack of input guidance. The description fails to provide enough information for effective tool invocation.

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

Parameters1/5

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

The only parameter is 'kwargs' with no description inside the schema. Schema coverage is 0%. The tool description adds no meaning about what keys or values are expected, leaving the agent completely in the dark.

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

Purpose3/5

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

The description 'Update email flags' clearly states the action and resource, but it is vague regarding what flags are available and how it differs from sibling tools like 'move_email' or 'forward_email'. It lacks specificity to fully differentiate.

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 is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without usage direction.

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

move_emailC

Move email to another folder

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	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 are provided, so the description must cover behavioral traits. It only states 'move' without indicating whether the operation is destructive, if it requires special permissions, or any side effects. This is insufficient for an agent to understand the tool's impact.

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 very short and front-loaded, but it lacks structure. It is one sentence with no additional details, which is borderline under-specification rather than conciseness.

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?

Given the lack of annotations and poor parameter documentation, the description fails to provide essential context. Although an output schema exists, the description does not explain return values. The tool's simplicity does not excuse the missing details.

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

Parameters1/5

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

The schema has a single parameter 'kwargs' with 0% description coverage, and the description adds no clarification. The agent has no information on what 'kwargs' should contain, such as the email ID or target folder.

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 action ('Move email') and the resource ('to another folder'). It distinguishes from sibling tools like 'copy_email' and 'delete_email' by specifying the operation.

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 is provided on when to use this tool versus alternatives. For example, it does not explain when to use 'move_email' instead of 'copy_email' or 'delete_email', leaving the agent without context for selection.

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

ping_exchangeC

Check connectivity to Exchange

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must carry the full burden. It says 'check connectivity' but does not explain whether it makes a live API call, what the response format is, or what happens on timeout/failure. The output schema exists but is not provided here.

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 extremely concise—only one short sentence—but it lacks necessary detail, especially about parameters. It is not a model of efficient communication.

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?

Given the lack of annotations and poor parameter documentation, the description is incomplete. An agent cannot reliably invoke this tool without additional context about the kwargs structure.

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

Parameters1/5

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

The required parameter 'kwargs' is an object with zero schema description coverage (0%). The description provides no information about what keys or values 'kwargs' should contain, leaving the agent without guidance.

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 'Check connectivity to Exchange' clearly states the tool's purpose with a specific verb and resource. It distinctly differs from sibling tools like copy_email or create_contact.

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 purpose is straightforward, but no explicit guidance is given on when to use this tool versus alternatives or any preconditions. The simplicity somewhat mitigates this gap.

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

reply_emailC

Reply to an email

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action. It fails to disclose behavioral traits such as whether the tool sends the reply immediately, requires authentication, or modifies the original email. No side effects or safety info.

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

Conciseness2/5

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

The description is a single short sentence, but it is under-specified. Conciseness should not come at the cost of clarity; more details are needed to make it useful.

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

Completeness1/5

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

Despite having an output schema and sibling tools, the description provides no information about return values, error handling, or prerequisites. The single parameter is opaque, making the tool definition incomplete for practical use.

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

Parameters1/5

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

The schema has one parameter, 'kwargs', with 0% description coverage. The description does not clarify what 'kwargs' expects or how to structure it, leaving the agent unable to correctly invoke the tool.

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 'Reply to an email' clearly states the action (reply) and resource (email), differentiating it from siblings like forward_email or create_draft. However, it does not specify whether it replies to all recipients or just the sender, leaving minor ambiguity.

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 is provided on when to use this tool versus alternatives like forward_email or send_draft. No prerequisites or context (e.g., must have an existing email thread) are mentioned.

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

respond_to_inviteC

Respond to a calendar invite

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior2/5

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

No annotations provided, so description must carry full burden. It discloses no behavioral traits (e.g., side effects, idempotency, permissions). Only states the action without context.

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 sufficient substance. It is not well-structured to convey necessary details beyond the tool's basic function.

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?

Given the tool's likely complexity (responding to an invite with a decision), the description is incomplete. It does not mention required input fields (e.g., invite ID, response type) or expected output, despite an output schema existing.

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

Parameters1/5

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

The input schema has a single generic 'kwargs' parameter with no description and 0% schema coverage. The description adds no meaning to this parameter, leaving agents with no guidance on what to provide.

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

Purpose3/5

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

The description states 'Respond to a calendar invite', which gives a verb and resource, but it's vague—does not specify whether it accepts, declines, or tentatively responds. It adds minimal information beyond the tool name.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like 'update_event' or 'create_event'. No prerequisites or exclusions provided.

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

search_contactsD

Search contacts

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.5/5.0

Behavior1/5

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

With no annotations and a minimal description, the tool's behavioral traits (e.g., search scope, pagination, output format) are entirely undisclosed. The description provides no value beyond the name.

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

Conciseness2/5

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

The description is extremely concise (two words) but fails to provide necessary context. It is underspecified rather than efficiently informative, earning a low score.

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

Completeness1/5

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

Given the complexity (30 sibling tools, no annotations, no schema coverage), the description is woefully incomplete. The presence of an output schema is not leveraged, and critical details are omitted.

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

Parameters1/5

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

The input schema has a single parameter 'kwargs' with 0% schema description coverage. The description adds no information about how to use this parameter or what values it expects, leaving the agent blind.

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

Purpose2/5

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

The description 'Search contacts' is a tautology that restates the tool name without adding specificity. It does not differentiate from sibling tools like 'get_contact' or 'search_emails', leaving ambiguity about scope or behavior.

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 is provided on when to use this tool versus alternatives. There are no context signals or exclusions, requiring the agent to infer usage from the name alone.

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

search_emailsD

Search emails

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.8/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, filtering capabilities, or return format. The tool's behavior remains completely opaque.

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

Conciseness2/5

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

At only two words, the description is too brief and lacks necessary detail. While concise, it sacrifices informativeness, which is not a positive attribute in this context.

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

Completeness1/5

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

Given the absence of annotations, minimal schema, and output schema not described, the description fails to provide adequate context for an AI agent to use the tool effectively. It is completely insufficient.

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

Parameters1/5

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

The input schema has one parameter 'kwargs' with 0% description coverage, and the description offers no explanation of its purpose or expected structure. The description adds no value beyond the schema.

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

Purpose3/5

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

The description 'Search emails' is clear as a verb+resource, indicating the tool performs a search operation on emails. However, it does not differentiate from sibling tools like 'list_emails' or 'search_contacts', lacking specificity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool over alternatives. For example, it does not clarify how 'search_emails' differs from 'list_emails' or 'search_contacts', leaving the AI agent without direction.

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

send_draftC

Send a draft email

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It fails to mention side effects like whether the draft is deleted after sending, permission requirements, or any irreversible changes. The description only states the action without depth.

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

Conciseness2/5

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

While the description is short, it is under-specified rather than concise. It lacks critical details that could be added without increasing length significantly. Every sentence should earn its place, but this one does not provide enough value.

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

Completeness1/5

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

Given the tool's complexity (sending an email with side effects), the description is severely incomplete. It does not explain return values, error states, or behavior changes. Even with an output schema, the description should provide context about the sending process.

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

Parameters1/5

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

The input schema has a single parameter 'kwargs' with no description (0% coverage), and the description adds no information about what 'kwargs' should contain. This leaves the agent completely uninformed about required arguments.

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 'Send a draft email' clearly states the verb and resource, indicating the action of sending an email that was previously drafted. It distinguishes from siblings like 'send_email' which sends a new email, though it could be more explicit about operating on an existing draft.

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 is provided on when to use this tool versus alternatives such as 'send_email' or 'create_draft'. It does not mention prerequisites like having a draft to send, which would help agents decide appropriately.

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

send_emailC

Send a new email

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided; description fails to disclose behavioral traits like required permissions, side effects, or error conditions for a mutation operation.

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 very short but under-specified; it is concise but lacks structure and necessary detail.

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?

For a tool that sends email, the description omits critical context like required fields, output behavior, and differences from siblings, making it incomplete despite an output schema.

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?

Schema has a single parameter 'kwargs' with no description and 0% schema coverage. The description does not explain what keys or values are expected, adding no semantic value.

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 the tool sends a new email, but does not differentiate it from sibling tools like forward_email or create_draft.

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 such as create_draft or forward_email. No context provided.

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

update_contactC

Update a personal contact

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only says 'update' implying mutation, but does not mention whether updates are partial or full, required permissions, error handling, or side effects. This is insufficient 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.

Conciseness2/5

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

Extremely concise (one sentence) but at the expense of completeness. While every word earns its place, the description fails to provide necessary details, making it more under-specified than efficient.

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

Completeness1/5

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

Given one parameter with zero description coverage and no annotations, the description is woefully incomplete. It does not explain the return value (though an output schema exists), valid inputs for kwargs, or any constraints. The tool cannot be safely used.

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

Parameters1/5

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

The sole parameter 'kwargs' has no description in the schema (0% coverage), and the description provides no additional meaning. The agent has no idea what keys or values are expected, severely limiting the tool's usability.

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 'Update a personal contact' is a clear verb+resource statement. It identifies the action (update) and the target object (personal contact). However, it does not differentiate from sibling tools like update_event or update_contact's specific scope.

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 create_contact, delete_contact, or search_contacts. The description lacks any context about prerequisites, required IDs, or typical use cases.

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

update_eventC

Update a calendar event

ParametersJSON Schema

Name	Required	Description	Default
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.5/5.0

Behavior2/5

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

The description only indicates mutation ('Update') but does not disclose side effects, required permissions, or what happens with overlapping updates. Given no annotations, the description carries the full burden and falls short.

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

Conciseness2/5

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

While the description is very short, it sacrifices essential information. It is under-specified rather than concise, failing to earn its place by being unhelpful.

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

Completeness1/5

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

Despite the existence of an output schema, the description does not hint at the return structure, and the parameter is opaque. For a tool that updates calendar events, this is severely incomplete.

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

Parameters1/5

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

The only parameter 'kwargs' has no description, no properties defined in the schema, and the description adds no meaning. With 0% schema description coverage, the agent has no clue what to pass.

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 action ('Update') and the resource ('a calendar event'), which is distinct from sibling tools like 'create_event' and 'delete_event'. It is specific and informative.

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 is provided on when to use this tool versus alternatives like 'respond_to_invite' or under what circumstances updating is appropriate. There is no mention of prerequisites or limitations.

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.

31 tool updatesv0.1.0May 31, 2026
- First observedcopy_email
- First observedcreate_contact
- First observedcreate_draft
- First observedcreate_event
- First observedcreate_folder
- First observeddelete_contact
- First observeddelete_email
- First observeddelete_event
- First observedfind_free_slots
- First observedforward_email
- First observedget_attachment
- First observedget_contact
- First observedget_email
- First observedget_event
- First observedget_mailbox_info
- First observedget_my_availability
- First observedlist_calendars
- First observedlist_emails
- First observedlist_events
- First observedlist_folders
- First observedmark_email
- First observedmove_email
- First observedping_exchange
- First observedreply_email
- First observedrespond_to_invite
- First observedsearch_contacts
- First observedsearch_emails
- First observedsend_draft
- First observedsend_email
- First observedupdate_contact
- First observedupdate_event

Deploy Server

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

TDQS

C2.6/5.0

Scored 2026-05-31 20:06 across 31 tools

Disambiguation4/5

Most tools have distinct purposes, but `find_free_slots` and `get_my_availability` overlap in functionality (both deal with availability). Otherwise, email, calendar, and contact operations are clearly separated.

Naming Consistency5/5

All tool names follow a consistent `verb_noun` pattern in snake_case (e.g., `create_event`, `list_emails`, `send_email`). No mixing of conventions.

Tool Count3/5

With 31 tools, the server covers email, calendar, contacts, and folders comprehensively. However, the count is on the higher side for a single server, exceeding the typical 3–15 range, though still manageable.

Completeness4/5

The tool set provides CRUD for emails, events, contacts, and folders, plus search, send, reply, forward, and move. Minor gaps exist (e.g., no attachment creation, no folder update), but core workflows are well-covered.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

microsoft-exchangeOAuth
com.postgate-ai
Microsoft Exchange MCP server - hosted, multi-user, incl. Exchange on-prem & hybrid (EWS)
Email Calendar Management Communication
2
Incwo MCPOAuth
io.github.incwo
Secure MCP server for exploring incwo CRM data, documents, and email workflows.
CRM Email Documentation Access
2
Email Server C
live.alpic.staging
An MCP server that provides email capabilities, hosted on Alpic platform
Communication App Automation
2
Email Server
live.alpic.staging
An MCP server that provides email capabilities, hosted on Alpic platform
Communication App Automation
2

Related MCP Servers

OWA Exchange MCP Server
Email Calendar Management
nhype
A
license
A
quality
D
maintenance
MCP server for any Microsoft Exchange / OWA deployment. Gives LLM agents access to email, calendar, directory search, folders, availability, and meeting analytics via 30 tools.
Updated 7 months ago (2026-02-16 07:05 UTC)
30
8
MIT
owa-mail-mcp
Email Calendar Management Communication
mainpart
F
license
A
quality
B
maintenance
MCP server for corporate Exchange that provides access to email, calendar, and people directory via OWA JSON API.
Updated a month ago (2026-07-31 10:59 UTC)
20
-
ews-outlook-mcp
Email Calendar Management Workplace & Productivity
devsergioherrera
F
license
A
quality
B
maintenance
MCP server for Claude to access on-premises Outlook/Exchange mailboxes via EWS with NTLM authentication, providing tools for email, calendar, and contact management without relying on Microsoft 365 or Graph API.
Updated a month ago (2026-07-31 16:52 UTC)
18
-
Exchange EWS MCP
Email Calendar Management Communication
ShermanGu
A
license
Not graded
quality
A
maintenance
A local MCP server for on-premises Microsoft Exchange, connecting via EWS and NTLM. It provides mail, template, availability, and calendar workflow tools through stdio, with draft-first safety and Windows Credential Manager integration.
Updated 22 days ago (2026-08-21 07:01 UTC)
7
MIT

outlook-ews-mcp

Contents

Highlights

Tool catalog

System

Email

Calendar

Contacts

Typical use cases

Security notes

Quick start

Configuration

Request queue

Claude Desktop example

Smoke check

Docker

CI/CD

Development

Project notes

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers