Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@copilot-outlook-connector @copilot-outlook-connector Show my latest emails from today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local, reusable TypeScript STDIO MCP server for personal Microsoft accounts such as Outlook.com and Hotmail. Each account has an independent delegated grant and secure credential namespace. This is not an organizational Microsoft 365 connector, an app-only integration, a dashboard, or a native Copilot connector manifest.
Area | Included | Intentionally absent |
Structured search/list, message and paginated conversation reads, attachment metadata and bounded inert file bytes, unsent new/reply/reply-all drafts | Send, forwarding, move/archive/delete, categories, arbitrary MIME or header injection | |
Calendar | Discovery, event and instance reads, event creation/updates/deletion, attendee invitations, self-RSVP, whole-series and exact-occurrence operations | Calendar creation/deletion, sharing/ACL changes, contacts, this-and-following series splitting |
Availability | CalendarView-derived busy/common availability for explicitly selected accessible account/calendar sources | Organizational getSchedule/findMeetingTimes, arbitrary people-directory availability |
Safety | Durable request receipts, explicit accounts, OS credential storage, generation checks, human WebAuthn approvals | Agent |
This is not unrestricted Outlook parity. Search is structured Graph filtering, not Gmail syntax or a full-text consumer search promise. Conversations are mailbox-scoped conversationId queries, not Gmail thread resources. Pagination is not a consistent snapshot. Only file attachments are downloaded, at most 2 MiB; item/reference attachments and external images are not fetched. Drafts use Graph JSON APIs; Microsoft owns MIME serialization and reply headers.
All recurring edits, deletions, attendee-affecting operations and RSVPs require human approval. In ordinary Graph v1.0 responses, private creates are gated too: the provider does not supply the negative-sharing evidence needed to prove an exemption safe. Updates always remain gated: Microsoft's event-update documentation does not establish atomic conditional-write enforcement. The connector rechecks versions immediately before dispatch but does not claim an external-edit lock or conditional-write guarantee. See calendar contracts.
Related MCP server: Microsoft 365 MCP Server
Requires Node.js 22 or later, a desktop browser, and an available OS credential store. Clone and build the source:
git clone https://github.com/torosent/copilot-outlook-connector.git
cd copilot-outlook-connector
npm ci --registry=https://registry.npmjs.org
npm test
npm pack
node dist/cli.js helpFor another local installation, install the resulting copilot-outlook-connector-0.1.0.tgz into a directory you control:
npm install --prefix /absolute/path/to/local-install /absolute/path/to/copilot-outlook-connector-0.1.0.tgz
node /absolute/path/to/local-install/node_modules/copilot-outlook-connector/dist/cli.js helpThe package is marked private to prevent accidental npm publication. Nothing installs or edits Copilot configuration automatically. No repository or package publication is required.
Use a Microsoft public desktop client whose supported account types include personal Microsoft accounts and whose native redirect matches the connector's loopback policy. The recommended native redirect is http://localhost under Mobile and desktop applications. Do not add a secret to a desktop client or weaken an unrelated application's settings. If an existing registration is incompatible, create a separate suitable public client or make the specific registration change yourself.
Run node dist/cli.js help for the supported registration inspection/configuration and account commands. Registration inspection consumes only allowlisted application metadata; it is not token import or proof of current portal state. Configuration does not authenticate. Token-bearing exports and registrations declaring unsupported permissions are rejected. Use a separate least-privilege public client rather than weakening an existing application's configuration.
node dist/cli.js auth client inspect --file /absolute/path/to/application-manifest.json
node dist/cli.js auth client import --file /absolute/path/to/application-manifest.json
node dist/cli.js accounts add --client-id YOUR_PUBLIC_APPLICATION_ID
node dist/cli.js accounts listOnly deliberately invoking accounts add --client-id starts sign-in; the client selection is mandatory. accounts reauth ACCOUNT_ID may only reauthorize the same stable identity; accounts remove ACCOUNT_ID disables local access and cleans up local credential generations, not provider-wide consent. If either reports cleanupPending, unlock the credential store and run accounts cleanup ACCOUNT_ID. accounts cleanup without an ID retries all journaled inactive-generation cleanup.
Requested delegated permissions are User.Read, Mail.ReadWrite, Calendars.ReadWrite, openid, profile, and offline_access. Mail.ReadWrite grants broader mailbox mutation permission at OAuth level even though the connector exposes drafts only. Mail.Send is never requested. No application permissions, tenant impersonation, password flow or organizational fallback are used.
See authentication contract for exact commands, cache storage and issuer/account binding. No user-specific client ID, email or credential export belongs in reusable source, examples or test fixtures.
After local setup, print configuration from the actual installed path:
node /absolute/path/to/copilot-outlook-connector/dist/cli.js config printUse the emitted ordinary mcpServers entry with the GitHub Copilot app's Customize -> MCP flow or its supported MCP configuration editor. It contains an absolute Node executable, absolute CLI path, serve, and no credentials. Use a distinct server name, outlook-local; keep any Google server independent.
The output is inert. Printing configuration, help, doctor, STDIO discovery and empty-account listing do not start OAuth, enroll an authenticator, read existing vault entries or create account state. doctor reports local setup only, not successful Microsoft connectivity.
Bootstrap the authenticator yourself in a trusted CLI, outside an agent workflow:
node dist/cli.js approvals enrollThe separate Outlook enrollment cannot be reset through MCP. A gated operation returns pending_approval and a localhost review URL. The human inspects the immutable account, target, resource versions, attendees, recurrence and notification effects, then completes the enrolled authenticator's user presence and user verification ceremony. No allow-all setting or SDK elicitation response substitutes for this. Never automate enrollment or approval.
Every write requires an explicit accountId and a stable, caller-chosen requestId. Repeating the same request returns its durable receipt; reusing the ID for different normalized arguments fails. Use operation_status to inspect and operation_cancel to cancel only before dispatch. An outcome_unknown operation must not be retried with a new ID. Inspect Outlook manually first. Microsoft transaction IDs are an additional event-create aid, not permission for automatic retries.
The independent namespace is copilot-outlook-connector: macOS Keychain, Windows Credential Manager, or desktop Linux Secret Service through shell-free secret-tool. Linux never silently falls back to kernel keyutils. Locked/unavailable vaults fail closed. Install libsecret's tools and unlock a desktop Secret Service on Linux.
MSAL caches are encrypted at rest with per-account/generation authenticated encryption; small encryption keys live in the OS vault, avoiding Windows credential-size limits. Metadata, operation receipts and authenticator public keys live in private local state. Mail bodies and access tokens are not put in receipts. No token is exported or passed as a process argument.
This protects the supported tool boundary and rejects forged approval responses. It cannot protect against arbitrary code already running as the same OS user, a replaced connector binary, compromised server, OS account or authenticator. See security and operational limitations.
npm test
npm run smoke:packageThe package smoke builds a tarball, installs it with production dependencies only in an isolated temporary consumer, and exercises help/config/doctor/real STDIO discovery without credentials. It uses public-registry artifact URLs and integrity-cache installation, not a claim of fresh network downloads.
Offline fixtures do not establish native Windows/Linux behavior, physical-authenticator behavior, live app registration state or successful Outlook connectivity. Those require user-controlled platform acceptance. No live draft, invitation, RSVP or event mutation is part of automated acceptance.
List configured personal Microsoft accounts and delegated scopes, without OAuth or credential access. Choose explicit opaque account IDs for subsequent requests.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only behavior is already indicated by the readOnlyHint annotation, but the description adds a valuable behavioral note that the tool does not involve OAuth or credential access. The phrasing 'List configured... accounts' also implies it only returns existing configurations without side effects. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two clear sentences with no redundant or extraneous information. The structure front-loads the core purpose and then adds a short usage note, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers what the tool does and what kind of result it produces (a list of accounts and delegated scopes, including opaque IDs). It also explains how to apply that result in later steps, providing sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so 100% of parameters are covered by the schema. The description does not add parameter-level details because there are none to describe. This aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured personal Microsoft accounts and delegated scopes, with the verb 'List' specifying the action. It also differentiates this tool from credential-handling operations by explicitly noting it works without OAuth or credential access, and it clarifies the intended use of the output (choosing opaque account IDs for subsequent requests).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: it is the source for obtaining account IDs to be used in subsequent calendar and mail operations. It also warns that it does not handle OAuth or credentials, distinguishing it from auth-related tools. However, it does not explicitly name alternative sibling tools or provide conditional logic for when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an appointment or invitation with explicit Windows-zone local times and bounded Graph recurrence. Invitations require human WebAuthn review. Private guest-free creates are exempt only with provider-proven own/private calendar evidence; missing sharing evidence means review. No online meeting creation.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| accountId | Yes | ||
| requestId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Create' which is a non-destructive action, but the annotations set destructiveHint=true. This is a direct contradiction; the description does not disclose any destructive behavior, making the annotation misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and focused, conveying the essential purpose and key constraints without unnecessary detail. It uses clear, direct language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description does not mention what the tool returns (e.g., the created event). It also omits potential side effects or error conditions, leaving the agent without complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only calendarId has a description). The description provides some context about time zones and recurrence but does not explain most parameters (accountId, requestId, or the many nested event fields), leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates an appointment or invitation, and it distinguishes itself from sibling tools like calendar_update_event and calendar_delete_event. The mention of constraints like 'No online meeting creation' further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating calendar events and includes specific constraints (explicit Windows-zone local times, bounded recurrence, WebAuthn review exceptions). However, it does not explicitly state when to prefer this tool over alternatives, though the create action is fairly evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete only the explicitly reviewed single event, whole seriesMaster or verified exact occurrence. Human WebAuthn review is always required; organizer deletion sends attendee cancellations.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| accountId | Yes | ||
| requestId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds critical behavioral details: required human WebAuthn review and that organizer deletion sends attendee cancellations. This meaningfully increases transparency for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose and then adding critical caveats. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core deletion behavior and side effects, but does not mention potential asynchronous execution (suggested by operation_* siblings) or return values. Given the lack of output schema, this is a notable gap but not fatal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the `target` parameter by explaining single/series/occurrence modes, but it does not clarify `accountId`, `calendarId`, or `requestId`. Since schema coverage is low (only calendarId described), the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (calendar events), and distinguishes three specific deletion modes (single, series, occurrence). It aligns with the tool name and clearly separates it from update/create/RSVP siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for deletion) but does not explicitly compare against alternatives like calendar_update_event or calendar_rsvp. It gives a constraint ('only the explicitly reviewed') but lacks direct 'use this instead of...' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find common UTC slots across every explicit account/calendar source. Busy, tentative, OOF, working-elsewhere and all-day events block; unknown or incomplete data yields no slots.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| sources | Yes | ||
| maxSlots | No | ||
| stepMinutes | No | ||
| durationMinutes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the readOnlyHint annotation by specifying which event types block availability and that unknown or incomplete data yields no slots. It is consistent with the read-only and open-world annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, using two sentences to convey the core operation, blocking rules, and failure behavior. There is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers important behavioral edge cases and UTC scope, but because there is no output schema, it does not clarify the exact return shape or how slots are represented. An agent may still need to infer result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low; only nested calendarId has a description. The tool description does not explain key parameters like start, end, durationMinutes, maxSlots, or stepMinutes beyond their names and schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding common UTC availability slots across explicitly specified accounts/calendars. It also names the resource type and distinguishes the operation from calendar listing/creation by focusing on availability computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus sibling alternatives like calendar_free_busy or calendar_list_events. The description says what it does but not when an agent should prefer it over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive free/busy ONLY from explicitly selected accessible account/calendar sources via fully paginated calendarView. Personal getSchedule/findMeetingTimes are not supported. Any partial/failed/unknown source prevents common free time.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: pagination is used, unsupported personal scheduling endpoints are excluded, and any partial/failed/unknown source prevents a common free-time result. This goes beyond the readOnlyHint annotation and sets clear expectations for failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no redundant wording. It packs the core behavior, constraints, and failure semantics without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description sufficiently communicates what the tool produces (free/busy) and its main constraints. It could be slightly more explicit about the exact output shape, but the core context needed to invoke the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that sources must be explicit, accessible account/calendar selections, directly supporting the sources parameter. Start and end are self-explanatory as a time range and their format is enforced by the schema pattern, though the description does not elaborate on edge cases like inclusivity or timezone resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool derives free/busy exclusively from explicitly selected calendar sources, using a paginated calendarView. It also explicitly rules out personal getSchedule/findMeetingTimes, which distinguishes it from sibling scheduling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: only when free/busy should come from explicitly selected accessible calendar sources. It also cautions that unsupported scheduling APIs should not be expected, though it does not explicitly compare against siblings like calendar_find_availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a selected accessible calendar and its Graph-reported permissions. default resolves /me/calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately indicates a read-only operation, consistent with the readOnlyHint and non-destructive annotations. It does not describe error cases or authorization behaviors, but the annotations already cover the main safety aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, direct, and free of extraneous detail. Two sentences convey the core operation and the special default behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description covers the main input behavior and return focus. However, the lack of accountId semantics and the absence of any output schema or return-shape hints leave some gaps for an agent needing to call this tool correctly in a multi-account context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
calendarId is well described with the 'default' special value, but accountId has no schema description and is not explained in the tool description. Since one of two required parameters lacks semantic guidance, the description only partially compensates for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('a selected accessible calendar' plus its Graph-reported permissions). It also clarifies the special default value for resolving /me/calendar, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when calendar metadata or permissions are needed, and the default resolution is helpful. However, it does not explicitly contrast with sibling tools like calendar_list_calendars or calendar_get_event, leaving the selection of this tool somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one exact immutable event ID within the selected calendar, preserving master/originalStart and original zones.
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | ||
| accountId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only, non-destructive behavior is already clear from annotations and is reinforced by 'Read' and 'immutable'. The description adds that master/originalStart and original zones are preserved, but it does not describe return format, not-found behavior, or other side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler, redundant examples, or unnecessary details. It front-loads the action and object before the preservation nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-by-ID tool, the description conveys the core purpose and preserved fields, but no output schema exists and the return structure is not fully specified. AccountId semantics are also missing, leaving some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only calendarId has an inline description; eventId is only implied by the tool description and accountId is not explained at all. With schema description coverage at 33%, the description does not sufficiently compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Read' and a precise object: one exact immutable event ID within the selected calendar. This clearly distinguishes it from list/search/instance sibling tools and from calendar_get_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when the caller already has an exact event ID and needs the original master values, but it never explicitly states when to prefer this tool over calendar_list_instances, calendar_search_events, or other siblings. No exclusions or alternative conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover this explicit account's accessible calendars. Unknown permissions and partial results remain explicit; no calendars are created or shared.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint and destructiveHint annotations by stating no creation or sharing occurs. It also proactively mentions that unknown permissions and partial results remain explicit, providing transparency about potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences without unnecessary jargon or repetition. It front-loads the primary purpose and adds relevant clarifications in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no output schema, the description is sufficiently complete. It covers the tool's scope, non-mutating nature, and potential for partial results. It does not describe the return format, but that is not specified in the schema and is not critical for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, accountId, is self-explanatory by name, but the description does not add any additional meaning or clarify its format or scope. Since schema coverage is 0%, the description does not compensate, but the parameter's purpose is straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: discovering accessible calendars for a specified account. It also explicitly notes that no calendars are created or shared, distinguishing it from mutating calendar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It is clear this tool is for reading/listing calendars, and the note about not creating or sharing implies when to avoid using it. However, it does not explicitly contrast with other read-only calendar tools like search_events, though the distinct purpose is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bounded UTC calendarView occurrences, exceptions and single events. Follows all safe pages up to limits; complete=false is never a complete/free result.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| limit | No | ||
| start | Yes | ||
| accountId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explaining pagination behavior and the semantics of complete=false. It accurately reflects the read-only nature and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and contains no irrelevant or redundant content. The two sentences deliver the key semantic points without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of an output schema, the description covers important behavioral context such as pagination and boundedness. It does not describe response fields or error cases, but those are not strictly required for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only calendarId has a schema description; accountId, start, end, and limit receive no explicit explanation in the description. The description implies UTC and boundedness but does not clarify parameter roles or format expectations beyond the schema's regex and bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as reading calendarView data and specifies the scope (bounded UTC occurrences, exceptions, and single events). It is distinguishable from sibling tools like calendar_search_events and calendar_list_instances, though the term 'calendarView' could be slightly more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful pagination guidance ('Follows all safe pages up to limits') and clarifies the meaning of complete=false, which helps callers understand result completeness. However, it does not explicitly state when to prefer this tool over alternatives such as calendar_search_events or calendar_list_instances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get exact occurrence/exception IDs from a verified seriesMaster in a bounded window. Use returned ID, master and originalStart for occurrence actions; never derive IDs from dates.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| accountId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. | |
| seriesMasterId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by mentioning the requirement of a 'verified seriesMaster' and a 'bounded window.' It also alerts users not to derive IDs from dates, a valuable operational caveat. The read-only nature is already covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, directly states the main purpose first, and includes a clear usage directive. It is concise and well-structured without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains what the tool does and how to use the returned data, referencing key fields. It does not mention pagination, error cases, or the exact response list format, but for a read-only instance lookup, the provided information is sufficient for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies start and end as defining a 'bounded window' and seriesMasterId as needing a 'verified seriesMaster.' It also references 'originalStart' in the response, which helps understand the return shape. However, accountId is not explained beyond its name, and calendarId's description in the schema is not reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'Get' and specifies the resource: 'exact occurrence/exception IDs from a verified seriesMaster in a bounded window.' It also distinguishes this from general event listing by focusing on recurring series instances and explicitly mentions use for occurrence actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides practical guidance on how to use the results ('Use returned ID, master and originalStart for occurrence actions') and warns against a common mistake ('never derive IDs from dates'). However, it does not explicitly compare to sibling tools like calendar_list_events, leaving the choice of this tool vs. alternatives somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Respond only as the actual authenticated attendee of a default-calendar invitation. Requires explicit sendResponse=true and human WebAuthn review; no attendee identity override. Declining may remove the event; Graph actions have residual external-edit races.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| comment | No | ||
| response | Yes | ||
| accountId | Yes | ||
| requestId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. | |
| sendResponse | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals destructive potential ('Declining may remove the event') and open-world risks ('external-edit races'), which aligns with the annotations. It could mention additional side effects like organizer notifications, but the key behavioral implications are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three terse sentences, leading with purpose and followed by constraints and side-effect warnings. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, prerequisites, and caveats, but omits any mention of return values or result shape, and does not clarify the complex occurrence/series targeting fields. Given the schema's complexity and absence of an output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only calendarId has an inline description; the description itself does not explain target's union variants, requestId, response values, comment usage, or occurrence-specific fields. Most parameters require inference from names and types, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Respond'), the resource ('invitation'), and the scope ('actual authenticated attendee of a default-calendar invitation'). It also differentiates from identity override, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage constraints (requires sendResponse=true and human WebAuthn review) and important caveats (declining may remove the event, external-edit races). It does not explicitly compare to sibling calendar tools, but the purpose and constraints make appropriate usage reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Literal case-insensitive subject/bodyPreview search over an explicitly selected, bounded calendarView. Partial reads produce partial search results.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| limit | No | ||
| query | Yes | ||
| start | Yes | ||
| accountId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral note that partial reads produce partial search results, which is relevant given the openWorldHint annotation. The readOnly and destructive safety aspects are already covered by annotations, and the description supplements these with search-specific behavior without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It directly communicates the core operation, search matching behavior, and an important partial-read caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description provides sufficient context for the main input behavior and warns about partial reads. It does not cover error cases, sorting, or timezone handling, but those are not essential for basic invocation and the core semantics are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has minimal parameter descriptions (only calendarId is described), so the description partially compensates by explaining query semantics and the bounded/selected calendar view. However, it does not explicitly clarify start, end, accountId, or limit beyond what their names and schema constraints imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a literal, case-insensitive search over calendar event subject and bodyPreview fields, within an explicitly selected and bounded calendar view. This distinguishes it from listing or fetching events, especially given the sibling calendar_list_events tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (text-based search on event subject/bodyPreview) but does not explicitly contrast it with alternatives like calendar_list_events or calendar_get_event. It provides some context by describing the search semantics, but lacks direct 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch ONLY supplied fields on an organizer event. ALL updates require human WebAuthn review. Explicit seriesMaster or verified exact occurrence targeting; no this-and-following. Online meeting body editing is rejected. Resource re-read is not atomic concurrency control.
| Name | Required | Description | Default |
|---|---|---|---|
| patch | Yes | ||
| target | Yes | ||
| accountId | Yes | ||
| requestId | Yes | ||
| calendarId | Yes | Exact calendar ID from discovery, or "default" to resolve /me/calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral aspects: all updates require human WebAuthn review, online meeting body editing will be rejected, and resource re-read is not atomic concurrency control. These go beyond the annotations and give the agent a realistic picture of side effects and safeguards, though it does not describe return values or error formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured, using short declarative sentences to communicate key points without redundancy. It packs essential information into four sentences, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema (nested objects, many enums), the description provides enough context about the operation's purpose, targeting rules, and concurrency caveat. It does not mention output format or error handling, but the absence of an output schema and the presence of other tool documentation partially mitigate this. It could be more complete by clarifying what 'verified exact occurrence' means or how the WebAuthn review affects execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds almost no per-parameter detail. It mentions 'Patch ONLY supplied fields' for the patch object and 'Explicit seriesMaster or verified exact occurrence targeting' for target, but does not explain accountId, calendarId, requestId, or clarify the patch structure. The schema description coverage is only 20%, and the description does not fill that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Patch ONLY supplied fields on an organizer event.' It is unambiguous that this is a partial update operation on an event, and additional constraints (WebAuthn review, targeting rules) reinforce the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage constraints: 'Explicit seriesMaster or verified exact occurrence targeting; no this-and-following' and 'Online meeting body editing is rejected.' These tell the agent when to use the tool and what limitations exist. It does not name alternative tools, but the constraints are sufficient to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an UNSENT draft only. Explicit accountId and durable requestId required. Supports Unicode JSON bodies and validated To/Cc/Bcc; HTML is attribute-free formatting only. No send capability exists.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | No | ||
| bcc | No | ||
| body | Yes | ||
| subject | Yes | ||
| accountId | Yes | ||
| requestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the operation as creating an unsent draft and explicitly states no send capability, but the annotations include destructiveHint=true, which contradicts the non-destructive nature of creating a draft. This mixed signal reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and information-dense, with no filler. Each sentence adds meaningful constraints or capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and complex nested parameters, the description covers key constraints but omits expected return behavior, idempotency implications of requestId, and any error conditions, leaving gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds context about validated To/Cc/Bcc, Unicode JSON bodies, and HTML formatting restrictions, but does not explain the purpose of requestId, the body object's format/content fields, or the nested recipient structure beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates an unsent draft, requires accountId and requestId, and explicitly notes that it does not send emails. This distinguishes it from sending and reply-draft tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit requirements (accountId, requestId) and limitations (no send, HTML attribute-free), but does not directly contrast with sibling tools like mail_create_reply_draft or when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an UNSENT reply/reply-all using Graph createReply/createReplyAll. Graph derives Reply-To, recipients and conversation headers from the source; arbitrary recipient/header overrides and sends are unavailable. Source versions are rechecked, not atomically locked.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| mode | No | reply | |
| accountId | Yes | ||
| messageId | Yes | ||
| requestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotations: the draft is unsent, Graph derives recipients/headers, no sends are possible, and source versions are rechecked but not atomically locked. There is no contradiction with the readOnlyHint or destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two focused sentences that convey the core behavior and important limitations without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operational context—draft creation, derived recipients, no send capability, and concurrency semantics. It does not mention return values or success indicators, but this is partially mitigated by the absence of an output schema and the clarity of the intended side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is self-explanatory at a structural level, but the description provides no parameter-specific semantics. In particular, requestId and accountId are not explained, and the relationship between messageId and the source message is only implied by the phrase 'from the source.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an UNSENT reply/reply-all') and identifies the underlying Graph operations, distinguishing it from a generic draft tool. It also explicitly notes that sends are unavailable, which clarifies the intended scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains key usage constraints: recipients and headers are derived by Graph, arbitrary overrides and sends are unavailable, and source versions are rechecked rather than locked. It does not explicitly name the alternative generic draft tool, but the constraints make the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List inert attachment metadata for a message, with account-bound pagination. Does not download attachment content.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| accountId | Yes | ||
| messageId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and destructiveHint false. The description adds specific behavioral details: it lists metadata only, does not download attachment content, and is 'inert', reinforcing side-effect-free behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary action, and includes only essential details. No redundant wording or unnecessary jargon, making it highly efficient and directly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function, non-download behavior, and pagination, which is adequate for a simple listing tool. It does not specify the shape of the returned metadata, but given no output schema and the tool's straightforward nature, it is reasonably complete. A minor gap is the lack of return format hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no per-parameter descriptions, and the tool description provides minimal guidance. It mentions 'account-bound pagination' hinting at cursor usage, but does not explain the role of accountId, messageId, or cursor explicitly. Given 0% schema coverage, the description should compensate but does not sufficiently clarify parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (attachment metadata for a message), and explicitly distinguishes itself from downloading content. The phrase 'inert attachment metadata' and 'Does not download attachment content' make the purpose unambiguous even among siblings like mail_read_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need metadata without content) and notes 'account-bound pagination' for iteration. However, it does not explicitly contrast with mail_read_attachment or state a direct condition for when to choose this over alternatives, so it is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file attachment as bounded inert base64 bytes (up to 2 MiB). Item and reference attachments are rejected; no URL is followed and nothing is executed or written to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| maxBytes | No | ||
| accountId | Yes | ||
| messageId | Yes | ||
| attachmentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (base64), size bound, rejection behavior, and safety guarantees. This goes beyond the readOnly/destructive annotations by detailing specific limits and side-effect-free behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The main action is front-loaded, and additional constraints are presented efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple read tool: it states the action, output format, size limit, and safety behavior. No missing information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with patterns, formats, and constraints, so baseline is 3. The description adds minimal parameter-specific detail (e.g., size limit relates to maxBytes) but doesn't explain accountId, messageId, or attachmentId beyond what schema already defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Read' and the resource 'file attachment', distinguishing it from sibling tools like mail_list_attachments (list) and mail_read_message (read message). The description makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage constraints: size limit (2 MiB), rejection of item/reference attachments, and safety instructions (no URL follow, no execution, no disk writes). While it doesn't explicitly contrast with alternatives, the context is clear from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of messages sharing conversationId in this mailbox. No Gmail thread resource is assumed; follow nextCursor with the same account, conversation and pageSize for complete results. No snapshot or cross-mailbox completeness guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| pageSize | No | ||
| accountId | Yes | ||
| conversationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false. The description adds important behavioral details about pagination and the lack of snapshot/cross-mailbox guarantees, which complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey the core action, pagination behavior, and limitations. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains pagination and guarantees but lacks details about the return format or fields. Since there is no output schema, the description should state what a message page contains, but it does not. It is adequate for basic usage but incomplete for fully informed calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explicitly describe any parameters. While conversationId and pageSize are implicitly referenced, accountId and cursor are not mentioned, and the schema provides no per-parameter descriptions. The description adds minimal value beyond the schema patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one page of messages sharing a conversation ID, distinguishing it from mail_search and mail_read_message. The verb 'read' and resource 'conversation messages' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on pagination ('follow nextCursor') and states limitations (no snapshot, no cross-mailbox guarantee). It implies use for iterating through a conversation but does not explicitly contrast with alternatives like mail_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one immutable message ID, with bounded inert content and attachment metadata. Does not mark read, fetch images or execute content.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| messageId | Yes | ||
| maxBodyChars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description explicitly states that it does not mark messages as read, does not fetch images, and does not execute content. This provides additional transparency about side effects and safety, which is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences to convey the core functionality and exclusions. Every word contributes to the meaning, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides a reasonable overview of what is returned (bounded content and attachment metadata) and what is not done. However, it does not elaborate on the structure of the response or potential error behavior, leaving some ambiguity for a tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the three parameters (accountId, messageId, maxBodyChars). Schema coverage is 0%, and the description fails to compensate by explaining the meaning or purpose of these parameters. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single message by ID, and specifies that it returns bounded content and attachment metadata. It also explicitly lists what it does not do (mark read, fetch images, execute content), which helps distinguish it from other mail-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implicit guidance by stating what it does not do, but it does not explicitly mention when to use this tool versus alternatives like mail_read_conversation or mail_search. There is no explicit 'use this when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List/search messages across an intentional account selection using structured sender, subject and date filters. Includes mailbox folders such as Deleted Items. Not Gmail syntax or full-text search. Each account has independent pagination; repeat the identical filters/pageSize with its cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | ||
| accounts | Yes | ||
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive; the description adds relevant behavior such as including Deleted Items, per-account cursors, and requiring identical filters/pageSize when paginating. No statement contradicts the readOnly/openWorld annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences, front-loaded with purpose, followed by constraints and pagination usage. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, filter style, folder scope, and pagination mechanics for a list/search tool. It does not describe output ordering or return shape, but given no output schema and the search/list nature, this is a reasonable completeness level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself documents names and formats, and the description adds the key semantic layer: structured sender/subject/date filters, account selection, and cursor/pageSize pagination behavior. It does not walk through every filter, but property names and formats make them self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it lists/searches messages across selected accounts and explicitly distinguishes from full-text/Gmail-syntax search; resource and action are clear. The 'Includes ... Deleted Items' note further defines scope, and the pagination note distinguishes this multi-account batch behavior from single-message siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage boundaries: structured filters only, not full-text/Gmail syntax, and explains how pagination works per account. It could be stronger by explicitly naming mail_read_message as the single-message alternative, but the constraints are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a pending operation before dispatch. Does not undo an already-dispatched Outlook action.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds that it only affects pending operations and has no effect on already-dispatched actions. This provides important behavioral context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. It efficiently conveys the action, the precondition, and the limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cancellation tool with only two required parameters, the description covers what it does, when it applies, and what it does not do. No additional information is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has no descriptions for the parameters, the tool name and description make it clear that operationId refers to the operation to cancel and accountId identifies the account. The description sufficiently compensates for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a pending operation before dispatch, and explicitly clarifies that it does not undo an already-dispatched action. This makes the purpose unambiguous and distinct from operation_status or other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for use (only pending operations before dispatch) and explicitly excludes dispatched operations. It does not explicitly name a sibling tool like operation_status, but the context makes the appropriate usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the status of an explicitly selected account's write. An unknown outcome must never be blindly retried.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description builds on this by warning about unknown outcomes. This adds valuable behavioral context beyond the annotations, though it does not detail return behavior or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with no unnecessary words or repetition. It efficiently communicates the core action and a key safety caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action and a safety caveat, but it lacks details about what status values are returned, how to interpret the result, and what distinguishes a successful read from an unknown outcome. This leaves some gaps for an agent trying to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, and the description only indirectly references 'account' and 'write' without explicitly explaining accountId or operationId. Given the two required parameters, the meaning of operationId as the write operation identifier is not clearly conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the status of a write operation for a specific account, which distinguishes it from operation_cancel and other account-related tools. The phrase 'account's write' is slightly ambiguous but adequately conveys the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a cautionary note about not blindly retrying unknown outcomes, which provides some usage guidance. However, it does not explicitly state when to use this tool versus alternatives like operation_cancel, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0accounts_listcalendar_create_eventcalendar_delete_eventcalendar_find_availabilitycalendar_free_busycalendar_get_calendarcalendar_get_eventcalendar_list_calendarscalendar_list_eventscalendar_list_instancescalendar_rsvpcalendar_search_eventscalendar_update_eventmail_create_draftmail_create_reply_draftmail_list_attachmentsmail_read_attachmentmail_read_conversationmail_read_messagemail_searchoperation_canceloperation_statusMost tools are clearly separated by domain and action, such as calendar_get_event vs calendar_list_events and mail_read_message vs mail_read_conversation. A few pairs could require attention, like calendar_free_busy vs calendar_find_availability or mail_list_attachments vs mail_read_attachment, but the descriptions clarify the distinctions.
The dominant pattern is domain_verb_noun with snake_case, but several names deviate: accounts_list, operation_cancel, operation_status, and calendar_free_busy do not follow the verb-first convention. This makes the naming somewhat mixed despite consistent domain prefixes.
22 tools sits in the upper range and feels slightly heavy for a single connector. The count is defensible because it covers calendar, mail, drafts, attachments, availability, and operations, but it is above the ideal 3-15 range.
Calendar lifecycle is well covered including create, update, delete, RSVP, and availability, and mail covers read, search, drafts, and attachments. However, common mail actions such as send, delete, and folder management are absent, and the descriptions repeatedly state these are unsupported, leaving notable gaps in the mail domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Permissioned access to Outlook, OneDrive and Teams via the user's own Microsoft account
Read, search, send, organize, draft and schedule email across your inboxes from any MCP client.
Read email/chat conversations, messages, contacts and teams; draft, send and update threads.
Manage Microsoft 365 email, calendar, contacts and inbox rules via the Graph API with OAuth 2.0.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/torosent/copilot-outlook-connector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
