owa-mail-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct action and resource, but get_folders and get_calendars have slight overlap since both list folders for mail/calendar. The descriptions clarify the distinction, so ambiguity is low.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in lowercase snake_case. Verbs like get, find, send, create, and update are used predictably, making the API easy to learn and navigate.
Tool Count3/5
At 20 tools, the server is heavier than the typical 3-15 range. While the dual email/calendar scope justifies the number, it falls into the 'heavy' category and could feel overwhelming for agents.
Completeness2/5
Calendar operations are well-covered with full CRUD and response handling, but the email side has significant gaps: get_folders references move_email, which does not exist, and there is no update or edit operation for emails. This creates dead ends for workflows involving moving or modifying messages.
Average 4.3/5 across 20 of 20 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, so the safety profile is covered. The description adds what specific data fields are returned (body, attendees, attachment IDs), but does not disclose any additional behavioral traits such as error conditions or external dependencies.
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 concise phrase, front-loaded with the key concept 'Full calendar event', and every word adds value. No superfluous information or repetition.
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 presence of an output schema and strong annotations (read-only, idempotent), the description adequately complements the structured data. It highlights the key return elements without needing to explain return values in detail, and the tool is simple enough that the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with item_id described as coming from get_calendar_events and body_format explained as text vs html. The description does not add any parameter-specific semantics beyond what the schema already provides, so the baseline score applies.
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 specifies that the tool returns a full calendar event including body, attendee response statuses, and attachment IDs. This distinguishes it from siblings like get_calendar_events (list) and get_attachment (single attachment), even though it lacks an explicit verb.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it retrieves a single event by ID or contrast it with get_calendar_events, so usage context must be inferred from the name and schema.
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 annotations (destructiveHint=true), the description adds 'Sends immediately,' which signals that the action is executed without delay, and 'with its attachments,' clarifying that attachments are preserved. No contradiction with 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 short sentences that immediately state the core function and a behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple forward operation, the description covers the primary behavior and timing. The schema and output schema provide parameter and response details. It could have noted that it requires an existing item, but the schema makes that 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?
All 4 parameters are fully documented in the schema with descriptions (100% coverage), so the description's omission of parameter details is acceptable. The description itself does not add parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Forward' and identifies the resource ('an email with its attachments'), clearly distinguishing it from send/reply tools. The phrase 'with its attachments' adds a key characteristic.
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?
The description gives no guidance on when to use this tool versus alternatives like 'send_email' or 'reply_email'. No exclusions or alternative tool references are provided.
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 indicate readOnlyHint false, destructiveHint false, and idempotentHint false, so the agent knows it's a non-destructive write. The description adds valuable behavioral context: with no attendees, it becomes a private appointment and nothing is sent. This goes beyond annotations and clarifies the invitation 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 sentences, front-loaded with the core action, and no filler. Every word earns its place. The second sentence adds crucial behavioral nuance without bloating the description.
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 14 parameters, full schema descriptions, and an output schema, the description need not re-explain return values or parameter details. It covers the essential high-level behavior (creation, recurrence, attendee invites, privacy). Slightly more context about when recurrence or attendees are used could help, but the schema and annotations fill that gap adequately.
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 description coverage is 100%, so the baseline is 3. The overall description does not add parameter-specific meaning beyond what the schema already provides; it only mentions invite attendees, which is also captured in the attendees parameter description. No additional semantic value is added.
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 a calendar event'), the resource (calendar event), and key distinctions (one-off or recurring, invite attendees). It is easily distinguishable from sibling tools like get_calendar_events, update_event, and cancel_event by its explicit create verb and scope.
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 context (creating events) but does not explicitly state when to use this tool over alternatives or provide exclusions. The note about no attendees affecting privacy is a usage condition, but no alternative tools are mentioned. It is adequate but not explicit.
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 destructive, and the description adds the important qualifier that deletion moves to Deleted Items by default. It doesn't highlight that hard_delete is irrecoverable, but the schema covers that; no contradiction with 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?
One short sentence that is front-loaded and contains no filler. It states the action and the key default behavior efficiently.
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 delete operation with full schema coverage, annotations, and output schema, this description is mostly sufficient. It lacks explicit usage alternatives, but the name and siblings make the purpose clear; a small mention of hard_delete's irreversibility would improve completeness but is not necessary given schema.
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 both parameters at 100% with descriptions. The description's phrase 'to Deleted Items by default' reinforces the hard_delete default but adds no information beyond schema; baseline 3 is appropriate.
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 specific verb 'Delete' and resource 'email', and adds default behavior 'to Deleted Items'. This clearly distinguishes from sibling event actions and makes the tool's scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied by the tool name and sibling context, but the description doesn't discuss alternatives or conditions like when a hard delete is appropriate.
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?
Annotations already declare readOnlyHint=false, so the description's 'download to disk' aligns with that. It adds the return-path behavior and the mail/calendar applicability. However, it doesn't disclose pitfalls like filename collisions or permission requirements. With annotations covering the safety profile, a 3 is appropriate.
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, front-loaded with the core action. No redundant 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?
The combination of annotations, 100% schema coverage, and the description's clear scope makes the tool usable. The only missing context (where attachment_id comes from) is provided by the parameter description. Output schema exists, so return values need no explanation. A 4 reflects a minor gap: no explicit workflow advice, though it's implied.
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 covers 100% of parameters with descriptions, and the description itself contains no parameter details. It relies on the schema, which already explains attachment_id source, filename override, and target_dir default. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download') and resource ('attachment'), stating it saves to disk and returns a path. This clearly distinguishes it from sibling tools like get_email or get_event, which handle the parent objects.
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 explicitly states it works for both mail and calendar attachments, giving clear scope. It doesn't mention alternatives or when-not-to-use, but no direct alternative exists among siblings. This is clear context without exclusions.
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 flag destructiveHint=true and readOnlyHint=false, so the description adds valuable context: it 'sends immediately' and 'quoting the original,' which warns the user that the action is irreversible and affects the email thread. This goes beyond the structured annotations 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 compact and front-loaded: two sentences that convey the core purpose, the quoting behavior, and the immediate-send consequence. Every word earns its place with no filler or repetition.
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 output schema, full annotation coverage, and complete parameter descriptions, the description sufficiently covers the tool's primary behavior. It could mention that replying includes the original text or the immediate-send consequence, which it does. Minor gaps like potential attachments or undo options are not necessary given the structured metadata.
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 covers 100% of parameters with descriptions, so the description does not need to repeat them. However, it adds no new parameter-level context beyond what the schema already provides, such as the significance of body_type or reply_all. The baseline of 3 is appropriate.
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 ('Reply to an email'), the resource (email), and key behavior (quoting the original, sending immediately). This distinguishes it from sibling tools like send_email and forward_email, which send new emails or forward existing ones.
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 you want to reply to an existing email) but does not explicitly contrast with alternatives like send_email or forward_email, nor provide exclusions. There is no 'when not to use' guidance, so it falls at the implied-usage level.
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 indicate a destructive write operation (destructiveHint=true, readOnlyHint=false). The description adds useful behavioral context by stating 'Sending is immediate — no confirmation step,' which informs the agent that the action is irreversible and immediate. It also introduces the draft-saving mode, going beyond the annotation baseline.
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-loaded with the main purpose, and contains no filler. Every word adds value, making it perfectly concise and well-structured.
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 both primary modes (send and draft) and highlights the immediacy of sending. The schema and output schema handle parameter details and return values, so the description is adequately complete for a tool with complex parameters, though it doesn't mention the recipient-ambiguity risk (which is addressed in the schema).
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 description coverage is 75%, meaning most parameters are already documented. The description adds minimal parameter-specific meaning, only indirectly referencing the `draft` parameter via 'save it to Drafts.' Since coverage is not high enough to warrant a 3 baseline automatically and the description doesn't compensate, a 3 is appropriate.
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 primary action ('Send an email') and the alternative ('save it to Drafts'), with a specific verb and resource. This distinguishes it from sibling tools like reply_email and forward_email, which focus on different email operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for sending a new email or saving a draft, but it does not explicitly mention when to use this tool versus replying or forwarding, nor does it mention any exclusions or alternatives. This is a clear but basic usage description without comparative 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 adds valuable behavioral context beyond the annotations: it mentions the output includes item counts and unread counts, explains that 'total' is the server's own count and trustworthy, and hints at depth behavior. This complements the readOnly/idempotent 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 three sentences, front-loaded with the main function, and every sentence adds value. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strong annotations, the description is fairly complete. It covers the purpose, output contents, and a key use case. It doesn't explicitly describe pagination behavior, but the offset parameter description covers that; the note about 'total' adds trustworthiness.
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 description coverage is 75%, so the schema already explains most parameters (depth, offset, parent). The description adds a use case (folder name to FolderId) that implies parent semantics, and the note about 'total' helps interpret pagination. However, it doesn't explain limit/offset beyond what the schema provides.
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 function: 'List mail/calendar folders with their ids, item counts and unread counts.' It also specifies the primary use case of converting folder names to FolderIds for find_emails and move_email, which distinguishes it from sibling tools like get_calendars.
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 explicitly says when to use the tool ('Use it to turn a custom folder name into the FolderId find_emails and move_email accept'), providing clear context. It doesn't explicitly mention alternatives, but given the sibling tools list, the intended use is 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?
Annotations already flag destructiveHint and readOnlyHint, but the description adds valuable context beyond them: it notifies attendees, only applies to passed fields (not a full replace), and for recurring events nothing changes until apply_to is supplied. These are meaningful behavioral 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 two short, purposeful sentences. The first states the action and side effect; the second clarifies the recurring-event constraint. No filler or repetition—concise and well-structured.
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 tool with recurring-event complexity and attendee notifications, the description covers the essential behaviors: partial update, notification, and the apply_to requirement. An output schema exists, so return details are not necessary. It lacks error/edge-case guidance but is sufficient for most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the schema already documents key parameters like apply_to, body_type, and send_updates in detail. The description's mention of apply_to being required repeats schema info without adding new meaning. It also does not compensate for the three undocumented parameters (body, subject, location).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and resource ('existing event'), and includes 'notify attendees' which distinguishes it from create/cancel/respond siblings. It also clarifies the partial-update behavior, making the tool's purpose unmistakable.
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 clearly implies use for modifying existing events ('Change an existing event') and provides context for recurring events (apply_to required). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full usage 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, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds valuable non-obvious behavior: single match returns full card vs. compact list for multiple matches, and the has_more caveat that it only means the page is full, not an honest total. This exceeds the structured data.
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 paragraphs, front-loaded with the purpose. Every sentence earns its place: the first defines the action, the second explains single vs. multiple results and the SMTP address relevance, and the third clarifies has_more behavior. No wasted words.
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 read-only lookup tool with an output schema and strong annotations, the description covers purpose, result format nuances, pagination caveat, and integration points with sibling tools. The output schema handles detailed return fields, so the description is complete for an agent to select and invoke 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?
Schema coverage is 75% (limit lacks a description), so the baseline is 3. The description does not add new parameter-level semantics beyond what the schema already provides for query, offset, and details. It indirectly references details expansion but does not explain parameter syntax or constraints further.
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 opens with a specific verb and resource: 'Look someone up in the corporate address book.' It clearly distinguishes this tool from siblings like find_emails or get_calendar_events by focusing on people lookup, and even mentions how results feed into send_email and create_event.
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 to look up a person and obtain their SMTP address for other tools like send_email and create_event. It does not explicitly state when not to use it or name alternative people-search tools, but the context is clear enough among the given siblings.
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 idempotentHint. The description adds behavioral context by specifying the response includes body, all recipients, and attachment IDs, which is useful for understanding what the tool returns. No contradictions.
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 sentence with high information density, front-loaded with 'Full email.'
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 tool has an output schema, and the description covers the key return contents. With 3 params all documented, the description is adequate for a simple read 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?
Schema coverage is 100%, with descriptions for item_id, body_format, and include_links. The description does not add additional parameter semantics beyond the schema, so baseline 3.
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 states 'Full email: body, all recipients, and attachment ids for get_attachment.' This clearly identifies the tool as a read operation for retrieving the complete email, distinguishing it from siblings like find_emails (search) and get_attachment (fetches attachments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the full email content and attachment IDs, specifically noting the dependency on get_attachment. It does not explicitly mention when not to use it, but provides clear context.
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 annotations by specifying that the tool makes one light authenticated call to the mailbox, not just a cookie-file check, and that the result covers both credentials and host reachability. This adds useful behavioral context about the network call involved, which annotations do not 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 compact and front-loaded with the primary purpose ('Is the OWA session live?'). The additional sentence provides essential detail about the method without redundancy. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description fully explains what the tool does, how it works, and its scope. There are no significant gaps.
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 tool has zero parameters, so the description correctly focuses on behavior rather than parameter syntax. The baseline for a no-parameter tool is 4, and the description adds no unnecessary parameter details.
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 defines the tool as a health check for the OWA session, using a specific verb ('check') and resource ('session'). It distinguishes itself from sibling tools (e.g., get_folders, send_email) by explaining it verifies connection health rather than performing a mailbox operation.
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 context for when to use the tool: to check if the OWA session is live and the host reachable. It notes that it is independent of any particular tool, implying it is a general connectivity check. While it doesn't explicitly name alternatives or exclusions, the unique purpose makes the intended use obvious.
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 a significant behavioral detail: slots are computed from actual busy blocks (absolute times) rather than the merged free/busy string, which is shifted by the mailbox time zone and would cause double-booking. This goes well beyond the annotations and gives the agent critical information about correctness.
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-loading the purpose and then adding a crucial caveat. Every sentence contributes value, with no fluff or repetition of schema/annotation content.
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 9-parameter tool with rich annotations and an output schema, the description covers the key purpose, the critical timezone pitfall, and a clear integration path to create_event. It provides the essential behavioral context an agent would need 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?
Schema description coverage is 89%, so the schema already documents most parameters. The description adds context about working hours and the output feeding into create_event, but does not detail individual parameter semantics beyond that. A baseline score of 3 is appropriate given the 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 states a specific purpose: finding concrete meeting slots where all attendees are free during working hours. It clearly distinguishes itself from siblings like get_user_availability by emphasizing 'everyone is free' and by suggesting a direct follow-up to create_event.
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 context: use this tool to find common free slots, and then feed the result into create_event. It also warns about the timezone-shifted merged free/busy string, implying this tool is the accurate choice. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behaviors: listing does not guarantee readability, access requires a probe request, check_access incurs a per-colleague cost, and closed calendars may still expose meeting subjects via get_user_availability. This adds significant non-obvious context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence summarizes the core function, and the second paragraph adds important nuance without redundancy. Every sentence contributes value.
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 covers the listing purpose, access semantics, probe cost, and a relevant alternative tool. With an output schema present, return value details are already handled externally. It fully addresses the openWorldHint by mentioning colleagues' calendars and the access uncertainty.
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 already provides a thorough description of check_access, including its cost and effect. The tool description adds motivation for why the parameter exists but no new parameter-level details, so it does not exceed the schema coverage baseline.
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 calendars in the sidebar, including whose calendars are accessible. This is a specific verb+resource+scope, distinguishing it from sibling tools like get_calendar_events and get_user_availability.
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 gives practical context: it explains when check_access is needed, notes that a listed calendar may not be readable, and points to get_user_availability as an alternative for meeting subjects on closed calendars. It lacks explicit 'when not to use' but provides clear situational guidance.
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 reveals critical behavioral traits beyond annotations: apply_to is required for recurring events and has material consequences, a sent decline cannot be recalled, and nothing is sent until the user supplies it. These details add significant context beyond the annotations (readOnlyHint false, idempotentHint true, destructiveHint false) and help the agent understand side effects and timing. No contradiction with 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 front-loaded: the first sentence states the core purpose immediately. The following two sentences provide necessary warnings about recurring events and sent declines without redundancy. Every sentence earns its place, and the structure aids quick comprehension.
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 has 5 parameters, an output schema, and moderate complexity, the description covers the most critical context (recurring event handling, irreversibility, and the fact that nothing is sent automatically). It does not elaborate on return values or authentication, but the output schema likely handles return details. The only minor gap is that it doesn't explicitly say what happens for one-off events, though the schema implies apply_to is ignored.
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 input schema already provides descriptions for all parameters (80% coverage). The description adds valuable nuance for apply_to, explaining that it is required for recurring events and that its choice carries irreversible implications. It also clarifies that nothing is sent until the user supplies the response, which indirectly highlights the notify_organizer parameter's default behavior. This goes beyond a simple restatement of schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Accept, decline or tentatively accept an event invitation.' It clearly identifies the tool's function as responding to invitations, which distinguishes it from siblings like create_event, update_event, or cancel_event. No ambiguity about what the tool does.
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 strong usage guidance for recurring events: apply_to is required, and it tells the agent to ask the user which they meant rather than guessing. It also warns about consequences (declining the series means out of all future meetings) and that a decline cannot be recalled. However, it does not explicitly state when to use this tool versus alternatives like send_email or create_event, so it misses explicit sibling differentiation.
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 critical behavioral traits beyond annotations: recurrences are expanded, there is no paging so 'total' is exact, and modifying recurring occurrences requires an explicit 'apply_to' in write tools. Annotations already confirm read-only and idempotent, and the description adds rich operational context 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 three short, focused paragraphs. The first sentence delivers the core function, the second explains recurrence implications, and the third covers paging behavior and tuning. Every sentence earns its place with no filler.
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 read-only listing tool, this description covers the essential behavioral quirks: recurrence expansion, exact totals due to no paging, and how to narrow results. The output schema exists, so return structure is already defined. The description is notably complete for the tool's complexity.
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?
All 5 parameters have thorough schema descriptions with 100% coverage. The main description adds cross-parameter context, such as 'the whole window is read every call' and how 'limit' acts as a safety cap, clarifying the interaction between start, end, and limit beyond the individual parameter 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 states exactly what the tool does: 'Calendar events in a time window, recurrences expanded.' This clearly distinguishes it from siblings like get_event (single event) and get_user_availability. The verb and resource are specific and 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?
The description provides explicit context: 'There is no paging and nothing to page — the whole window is read every call' and advises 'Narrow the answer by moving start/end.' It also mentions an explicit alternative in the person parameter description: 'for anyone else use get_user_availability.' It lacks a direct 'when not to use' contrast with get_event, but the guidance is strong.
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 annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral nuance beyond that: subjects appear conditionally based on sharing level, otherwise subject is null but busy intervals remain. It also documents the exact failure mode of get_calendar_events, giving agents practical expectations 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 compact and front-loaded: the first sentence gives the core function, the second paragraph explains an important edge case and sibling distinction, and the third gives a pointer to an alternative. No filler words; every sentence earns its place.
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 output schema and annotations, the description is complete enough. It covers the core use case, the key edge case (unshared calendars), the conditional subject behavior, and points to the alternative tool for a different scenario. The output schema handles return value details, so the description does not need to enumerate them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all 4 parameters, each with descriptions and defaults, so the baseline is 3. The description does not add new parameter-level semantics, but it does indirectly mention the output field 'subject' and how sharing level affects it, which relates to the people parameter. Still, the schema carries the main burden.
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 states a specific verb and resource: 'Read someone's schedule: their busy blocks, WITH MEETING SUBJECTS.' It also distinguishes itself from sibling tools by explicitly mentioning that get_calendar_events requires calendar sharing and that find_meeting_time is for group availability, making the tool's unique purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct usage guidance: 'Works for a colleague who has not shared their calendar folder' versus get_calendar_events which fails without sharing. It also gives a clear alternative for a different scenario: 'For "when can we all meet?" use find_meeting_time.' This is explicit when-to-use and when-not-to-use guidance.
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 crucial behavioral context: the cancellation notice cannot be recalled, the tool refuses to cancel events for non-organizers, and recurring events require apply_to before anything is cancelled. This enriches the annotation 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 and well-structured: three short paragraphs, each serving a distinct purpose (main action, authorization/alternative, recurring rule). No redundancy or filler; every sentence contributes to understanding the tool.
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 annotations, output schema, and full parameter coverage, the description is complete. It covers the action, recipient notification, irreversibility, authorization, alternative tool, and recurring behavior. The output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly highlighting the consequence of not supplying apply_to ('nothing is cancelled') and reinforcing that apply_to is required for recurring events, which is useful beyond the schema's static description.
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 explicitly states the action: 'Cancel an event YOU organize and notify the attendees.' It also distinguishes itself from sibling tools by clarifying that only the organizer can cancel and directing users to respond_to_event for declining someone else's event. This is a specific verb+resource with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: it refuses to cancel others' events and directs users to respond_to_event instead. It also specifies that apply_to is required for recurring events, and nothing is cancelled until provided, offering clear procedural guidance.
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 readOnly/idempotent annotations, the description discloses important behaviors: newest-first ordering, bodies omitted, pagination via total/has_more and both continuations, and unusual search behavior (total reports 0, no cursor). This adds significant context not available from 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 yet information-dense, front-loaded with the core purpose. Every sentence contributes meaningful detail, and the structure flows logically from function to limitations to pagination specifics.
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 7 parameters and output schema, the description covers all essential operational aspects: listing vs search, result contents, pagination mechanics, and exceptions. It is complete enough for an agent to select and invoke the tool correctly without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so baseline is 3. The description adds value by explaining how pagination parameters work in context ('take either for the next page') and clarifying that search lacks next_cursor, which goes beyond individual parameter 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 lists emails in a folder or searches the whole mailbox by text. It distinguishes itself from siblings like get_email and get_thread by explicitly noting bodies are excluded and pointing to get_email for full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for when to use this tool vs alternatives: 'full body, attachment ids and links come from get_email' and mentions 'for that use get_thread' in the schema. It also clarifies the two modes (folder listing vs search) and relevant pagination behavior.
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 critical behaviors not covered by annotations: bodies are excluded, messages are ordered newest first, and the meaning of 'has_more' with no offset/cursor is explained. This adds significant transparency beyond readOnlyHint and idempotentHint.
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 four sentences, each conveying essential information without redundancy. It front-loads the core purpose and immediately follows with usage distinctions and caveats, maximizing clarity per word.
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 presence of an output schema, the description need not list return fields. It covers the thread scope, ordering, body exclusion, and pagination limitations, making it fully complete for a read operation with no unsupported scenarios.
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 adds meaning to the 'limit' parameter by explaining that raising it is the only way to see more results since there is no offset/cursor. It also reiterates that item_id can be a conversation_id, though the schema already states this. This compensates for the schema's lack of description on 'limit'.
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 specifies the tool's function: reading an entire email conversation, ordered newest first. It distinguishes itself from sibling tools by explicitly contrasting with search (which only returns matched messages) and get_email (which returns a single message), making the unique 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'The only way to read a thread in full' and contrasts it with search and get_email. It also provides follow-up guidance on using get_email for message bodies, giving clear decision-making context.
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

Copy to your README.md:

[![owa-mail-mcp MCP server](https://glama.ai/mcp/servers/mainpart/owa-mail-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mainpart/owa-mail-mcp)

Score Badge

Copy to your README.md:

[![owa-mail-mcp MCP server](https://glama.ai/mcp/servers/mainpart/owa-mail-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mainpart/owa-mail-mcp)

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/mainpart/owa-mail-mcp'

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