copilot-outlook-connector

by torosent

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most 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.
Naming Consistency3/5
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.
Tool Count3/5
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.
Completeness3/5
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.
Average 4/5 across 22 of 22 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

copilot-outlook-connector MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![copilot-outlook-connector MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/torosent/copilot-outlook-connector/badges/card.svg)](https://glama.ai/mcp/servers/torosent/copilot-outlook-connector)

Score Badge

Copy to your README.md:

[![copilot-outlook-connector MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/torosent/copilot-outlook-connector/badges/score.svg)](https://glama.ai/mcp/servers/torosent/copilot-outlook-connector)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/torosent/copilot-outlook-connector'

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