apple-mail-mcp

by parasxos

Overview Schema Related Servers Score Discussions

Python

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 target distinct resources and actions, such as searching, reading, sending, scheduling, and mailbox management. The main ambiguity is between triage_plan and triage_plan_delete, and search_emails vs list_recent are somewhat similar, but the descriptions largely keep them separable.
Naming Consistency3/5
The toolset mostly follows a verb_noun snake_case pattern, but mailbox_create and mailbox_delete reverse the convention, list_recent and list_scheduled use adjectives rather than nouns, and doctor and audit are bare verbs. These inconsistencies are readable but not uniform.
Tool Count3/5
At 21 tools, the server sits in the heavy range and covers a broad scope including email reading, sending, scheduling, triage, mailbox admin, and diagnostics. A few specialized tools like doctor, audit, and triage_plan_delete make the set feel slightly larger than a typical email workflow requires.
Completeness3/5
The surface covers core workflows well: search, read, send, reply, draft, schedule, attachments, threads, and mailbox management. However, notable gaps remain, including no direct single-email delete or move, no draft update, and no mark-read or flag operations, which forces reliance on triage plans or workarounds.
Average 3.7/5 across 18 of 21 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 173 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It implies a read-only operation but does not explain recency ordering, pagination, permission requirements, or what happens with unfiltered accounts. The description adds little beyond what the name already says.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one wasted-word-free sentence and front-loads the core action. It is efficient, though it remains thin enough that most of the burden is carried by the schema.
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?
With no annotations and no output schema, the description is too sparce to fully contextualize the tool. It does not define 'recent', specify ordering, describe returned fields, or differentiate this from the many email-related sibling tools. An agent would need to infer significant details.
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 parameters have helpful schema descriptions, high schema_description_coverage, so the baseline is 3. The description's mention of optional scoping repeats what the schema already states; no additional param meaning or format details are offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (list) and resource (recent messages), and adds optional account/mailbox scoping. It does not explicitly contrast itself with sibling tools like search_emails or get_emails_bath, so it falls just short of strong differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as search_emails or get_thread. The phrase 'optimaly scoped' describes parameter behavior rather than usage context, and no exclusion or precondition is offered.
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 signal read/write and destructive hints, so the description's added 'capped Trash plan' and exact-sender rule provide some extra context. However, it does not explain side effects, what 'capped' means operationally, or what happens when this plan is applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the central constraint about exact sender matching is placed immediately after the main action. It could be more informative, but it is structured efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool that prepares a deletion plan, the description is too thin. It omits how a capped plan relates to the limit parameter, whether any deletion is performed immediately, and what distinguishes it from triage_plan or triage_apply.
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 parameters are already documented. The description's main semantic addition, exact sender matching, is also already stated in the from_addr schema, so it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action and object: preparing a capped Trash plan, and adds a concrete selection rule (exact sender match). It is clearer than the name alone, though it does not explicitly contrast with sibling tools such as triage_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool rather than triage_plan, search_emails, or triage_apply. The sentence states a behavior but not a decision context or exclusions.
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 disclose readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is established. The description adds one genuinely new behavioral detail — delivery can happen on 'local or Exchange-side' — which is useful context. However, it does not disclose the open-world side effects implied by openWorldHint=true or clarify that repeated calls create duplicate scheduled emails given idempotentHint=false. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste. The core scheduling action leads, and the local/Exchange-side distinction follows. It is appropriately short for the tool's complexity.
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?
Given 8 parameters with full schema coverage and an existing output schema, the description covers the essential scheduling intent. However, as a mutation tool with openWorldHint=true, it omits behavior an agent would benefit from knowing, such as whether scheduling creates a persistent entry visible in list_scheduled, or any limits on how far in advance delivery can be set. Adequate but not complete.
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 all eight parameters are documented in the input schema itself. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies — the schema does the heavy lifting and the description neither helps nor hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action — freeze an email now and schedule delivery later — which distinguishes it from immediate-send tools like send_email and draft tools like create_draft. The verb 'schedule' plus the delivery timing is specific enough to identify the tool's resource and behavior, though 'freeze an email now' is slightly creative and could confuse on first read.
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 on when to use this tool versus alternatives. The 'local or Exchange-side delivery' phrasing implies delayed delivery rather than immediate, and the sibling send_email exists, but the description never states 'use this for future delivery, send_email for immediate.' An agent must infer the usage context.
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?
Annotations already provide readOnlyHint=false, idempotentHint=false, and openWorldHint=true, but the description adds little behavioral context. It does not mention that sending is an external, irreversible side effect, nor does it disclose delivery-failure behavior, rate limits, or identity/authentication requirements. 'Standards-correct MIME' is a formatting detail rather than a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with the core action front-loaded: 'Compose standards-correct MIME and send it...' It is concise and easy to parse, though the phrase 'standards-correct MIME' contributes limited practical value for an agent selecting the tool.
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 schema covers all parameters and an output schema exists, so most invocation details are present. However, the description does not orient the agent within the large sibling set: it does not explicitly distinguish immediate sending from creating a draft or scheduling an email, and it omits caveats about the irreversible external effect of sending.
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 description's 'selected identity' phrase loosely maps to the from_identity parameter but adds no new meaning beyond the schema, which already documents all seven parameters thoroughly.
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 'send' and clearly refers to composing and delivering an email, with the added context of using a selected identity. This distinguishes it from siblings like create_draft and schedule_email, which do not immediately send.
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 the usage case: compose and send an email now through an identity. However, it gives no explicit when-to-use or when-not-to-use guidance, and it does not name alternatives such as create_draft, schedule_email, or reply_email.
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 only contain a title, so the description must carry behavioral weight. It discloses that both healthy and damaged records are returned, a non-obvious trait. However, it does not confirm read-only safety or describe helper behavior around the 'damaged' category.
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?
A single sentence with no filler, front-loaded with the verb and resource. Every word contributes to the intended scope.
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 tool has a simple two-parameter schema, but no output schema and no behavioral annotations. The description lacks definitions for 'damaged' and does not mention pagination or return format, which an agent might need 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?
The input schema already documents both parameters well, including the state enum and limit bounds. The description's 'by lifecycle state' only restates the state filter, adding no new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'List' and the resource 'scheduled-mail records', which distinguishes it from sibling tools like list_mailboxes. The phrase 'healthy and damaged' adds a useful classification but is not fully defined, slightly reducing clarity.
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 guidance or alternatives are mentioned. The context implies this is the tool for listing scheduled emails, but no exclusions or comparative guidance is provided.
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 description adds the behavioral detail that it reports a before/after snapshot, which goes beyond the annotations. It also notes that it asks Mail.app, indicating an external app interaction. Since annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the safety profile is covered. The description provides a bit of extra context but does not disclose any limitations or side effects beyond what the parameters suggest (wait and timeout).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler; it gets straight to the point. It front-loads the main action ('fetch new mail') and then adds the snapshot detail. It is concise and structured well, though it could arguably include a bit more structured detail, but it earns its place with its efficiency.
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 (two optional parameters, high schema coverage, and annotations covering safety), the description is mostly complete. It mentions the before/after snapshot, which is a key output behavior. The output schema exists, so return values need not be explained. The only minor gap is that it doesn't mention any prerequisites like Mail.app being running, but that is likely implied. Overall, an agent has enough to call it 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 schema description coverage is 100%, with both parameters (wait_seconds and timeout_seconds) fully described in the schema. The tool description does not add any parameter-specific information, but per the rubric, a baseline of 3 is appropriate when the schema covers the parameters comprehensively. No additional semantic value is provided by the description.
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 that the tool asks Mail.app to fetch new mail and reports a before/after snapshot. This is a specific action on a specific resource, and the snapshot detail adds unique behavior. However, it does not explicitly distinguish itself from sibling tools like search_emails or list_recent, though the verb 'refresh' and the snapshot concept make its role clear enough.
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 that this tool is for fetching new mail, which is a clear context for when to use it. However, it provides no explicit guidance about when not to use it or mentions any alternatives such as search_emails or get_email. The usage is implied by the action itself, but there is no direct comparison or exclusion.
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 signal a non-read-only, non-idempotent operation, and the description adds the behavioral guarantee of correct threading. It does not disclose whether the reply is sent immediately, how recipients are resolved, or any side-effect caveats beyond what the schema already exposes.
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?
A single front-loaded sentence communicates the core operation and its notable options without wasted words. It is appropriately sized for the tool's complexity.
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 schema and output schema cover parameters and return shape, but the description leaves room for ambiguity between sending a reply and creating a draft, and gives no routing guidance relative to send_email or create_draft. For a side-effectful email action this is a notable gap.
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 every parameter is already documented. The tool description only restates optional history, attachments, and reply-all without adding 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 a specific verb (Reply) and resource (email), and adds distinguishing behavioral details: correct threading, optional history, attachments, and reply-all. This differentiates it from sibling send_email, which lacks reply threading semantics.
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 action itself implies usage: it is for responding to an existing email rather than composing a new one. However, the description provides no explicit when-to-use guidance and does not mention alternatives like send_email, create_draft, or schedule_email.
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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description does not need to restate side effects. It adds valuable behavior beyond annotations: the tool searches 'local envelope data and full bodies' and sender filters are 'case-insensitive substring matches', which meaningfully shapes expectations. 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 a single, compact sentence that front-loads the operation and scope and follows with a useful behavioral detail. Every word contributes; no filler or repetition of schema content.
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?
With all 11 parameters documented in the schema, an output schema present, and annotations covering side effects, the description adds the missing context an agent needs: local data scope and substring case-insensitivity. It would be stronger with explicit sibling routing, but that gap does not make the invocation unclear.
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 description coverage is 100%, which earns a baseline 3, but the description adds genuine param semantics by specifying that sender filters are case-insensitive substring matches. This clarifies intended behavior for from_addr and to_addr beyond the schema wording.
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 uses a specific verb ('Search') and identifies the resource ('local envelope data and full bodies'), making the operation clear. It does not explicitly contrast with sibling tools like get_email or list_recent, but the 'local' scope plus search semantics prevent major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use search_emails versus siblings such as get_email, get_emails_batch, or list_recent; no alternatives are named and no exclusion conditions are given. An agent must infer trigger conditions from the parameter list, which is insufficient for good tool selection.
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 description discloses that the tool applies and verifies, adding value beyond annotations which already indicate destructive, non-read-only, and idempotent behavior. However, it does not detail what 'apply' changes, what happens to the plan (e.g., is it consumed or retained), or what 'verify' returns. Since annotations already cover the safety profile, the description adds some but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, and the primary action is front-loaded ('Apply one reviewed plan'). It efficiently conveys purpose without padding.
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 is short and does not explain what 'apply' does in terms of side effects or what 'verify' produces. Given the destructive and openWorld hints, more context on consequences would be valuable. An output schema exists and may cover return values, but the description alone leaves gaps about the operational impact for an automation agent.
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% - plan_id is fully described as 'Triage plan ID returned by a planning tool.' The tool description does not mention the parameter or add any semantics beyond the schema, so it provides no additional value. Baseline 3 is appropriate when the schema already documents the parameter fully.
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 'apply' with a specific resource 'reviewed plan' and adds 'verify each resulting mailbox state', which is clear and distinguishes it from siblings like triage_plan (which likely generates a plan) and triage_plan_delete (which deletes a plan). An agent can immediately infer the tool's core function without ambiguity.
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 phrase 'reviewed plan' implies the tool should be used after a plan has been created and reviewed, but the description does not explicitly state when to use it, when not to use it, or mention alternatives like triage_plan_delete. There is no explicit guidance about preconditions or which sibling to choose over another.
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 are all false hints, so they do not clarify side effects. The description adds that the result is a 'reviewable' plan, suggesting changes are not applied immediately, and it adds the case-insensitive substring behavior. However, it does not explicitly state that no mailbox changes are actually made, whether the plan is persisted, or what side effects occur when preparing it.
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 two short clauses and no filler. The core action, 'prepare a reviewable bulk-change plan,' is front-loaded, and the matching behavior is added as a useful secondary detail.
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 schema richly documents all 11 parameters and an output schema exists, so return-value details are covered. What is missing is workflow context: that the plan should be reviewed and then applied via triage_apply, and that preparing the plan does not itself apply mailbox changes. For a non-read-only tool with this many parameters, the one-sentence description is minimally sufficient but leaves important behavioral 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?
Schema coverage is 100%, so the baseline is 3 because parameter descriptions already exist. The description adds meaningful value by specifying that sender filters match case-insensitively as substrings, which is not stated in the from_addr/to_addr schema entries. It doesn't elaborate on every parameter, but the schema already handles those 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 verb 'prepare' and the object 'reviewable bulk-change plan' state a specific, concrete function: this tool stages changes for review rather than executing them. This distinguishes it from siblings like triage_apply. The generic title 'Prepare mailbox changes' is clarified by the description's focus on producing a plan.
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 explicit when-to-use guidance or alternatives. 'Reviewable bulk-change plan' implies a plan-then-apply workflow, and sibling triage_apply exists, but the description never says to use this before triage_apply or that triage_apply should be used afterward. The matching-semantics clause is about filtering behavior, not tool selection.
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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context that the resource is a 'local mutation ledger' and enumerates filter dimensions, which is useful beyond annotations. However, it does not describe return format or any additional behavioral nuances, though an output schema exists. This adds moderate value beyond 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 a single, efficient sentence that front-loads the primary action ('Read the local mutation ledger') and then lists the filter dimensions. There is no wasted wording, and every part contributes to understanding the tool's scope.
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 7 parameters, an output schema, and annotations fully covering safety, the description is largely complete. It explains the core function and the available filters. It does not explicitly mention output details, but the output schema presumably covers that. The only minor gap is that it doesn't state why one might use this tool (e.g., for debugging), but given its uniqueness among siblings, this is acceptable.
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 each parameter having a description, so the schema fully documents parameters. The description summarizes them as 'time, tool, event, plan, and operation filters', which maps to since/until, tool, event, plan_id, operation_id. This adds minimal meaning beyond the schema's own descriptions, so the baseline of 3 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 states the tool reads a 'local mutation ledger' and lists the specific filters (time, tool, event, plan, operation). This is a specific verb+resource combination that distinguishes it from all sibling tools, which are email-centric. The title 'Read the activity history' reinforces it, but the description goes further.
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 for inspecting mutation history, but does not explicitly state when to use it versus alternatives or provide exclusions. Since no sibling tool is similar, the need for explicit guidance is lower, but the description still lacks an explicit 'use this when...' statement. Thus, usage is implied but not elaborated.
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 indicate readOnlyHint=false (non-read-only) and destructiveHint=false (non-destructive), so the description should clarify side effects. It adds that the draft is stored server-side in the Drafts folder, which is useful, but it does not mention whether a new draft is always created, whether it overwrites, or what the response contains. Given the annotations, the description provides some added context but not comprehensive behavioral disclosure.
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 that is concise, front-loaded with the core purpose, and contains no redundant or irrelevant information. Every clause adds value, from 'never-sent' to 'selected identity'.
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 tool has an output schema, so return values are covered. The description covers the core action and key distinction (draft vs. sent) and mentions 'selected identity,' which relates to the from_identity parameter. Minor gaps exist: it does not explain behavior when from_identity is omitted or clarify whether a fresh draft object is always created, but these are not critical for 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 description coverage is 100%, so all six parameters are already described in the schema. The tool description adds no additional parameter-level detail beyond the overall purpose. Baseline 3 is appropriate since the schema does the heavy lifting and the description does not add meaning beyond that.
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 ('Create'), a resource ('draft'), and a precise location ('server-side Drafts folder'). It also clarifies the draft is 'never-sent,' which distinguishes it from send_email and reply_email. This 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for drafting rather than sending ('never-sent draft'), but it does not explicitly contrast with alternatives like send_email or reply_email, nor state when to choose this tool over them. There is no explicit 'when not to use' guidance, leaving the routing partially to inference.
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=true, destructiveHint=false, and idempotentHint=true. The description adds the specific behavior of saving to a configured temporary directory, which is beyond annotations and informs the agent of a side effect (writing a local file) that is still non-destructive. 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?
A single sentence that is front-loaded with the core action ('Save one attachment') and provides a concise purpose. No wasted words; every word earns its place.
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 tool is simple, has an output schema, and annotations cover safety. The description adds the essential behavior of saving to a temp directory. It lacks an explicit hint about needing to call get_email first, but that is inferable from the schema and sibling names. Overall, sufficient for a low-complexity 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 description coverage is 100%, so the schema fully documents id and attachment_id. The description does not add extra parameter-level meaning beyond noting 'one attachment' and the temp directory. Baseline 3 is appropriate when schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Save') and resource ('one attachment') with a purpose ('for reading'). It is distinct from siblings like get_email (which retrieves content) and get_thread (which retrieves threads), so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to read an attachment, but it does not explicitly state when not to use it or mention alternatives. There is no guidance on the prerequisite of calling get_email to obtain an attachment_id, though the schema description covers that. Thus, usage context is clear but exclusions/alternatives are absent.
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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating the exact areas under diagnosis (permissions, identities, transports, etc.), which goes beyond what the generic annotations convey. No contradiction detected.
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?
A single, well-structured sentence that leads with the verb and concisely lists the diagnostic scope. No filler, and every word adds value.
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 zero-parameter tool with an output schema (present but not detailed), the description covers the main intent and what it inspects. It does not describe the return format or how results are presented, but the existence of an output schema shifts that burden, and the summary of diagnostic areas is sufficient for an agent to invoke 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?
There are zero parameters, so the baseline is 4. The description correctly does not attempt to explain parameters that don't exist, and the schema confirms no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Diagnose') and a clear resource scope (permissions, identities, transports, scheduling, storage, indexing). It is not a tautology and conveys the tool's role as a health-check. However, it does not explicitly distinguish it from the sibling tool 'audit', which may have overlapping 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 implies the tool is used for diagnosing email setup issues but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like 'audit' or other diagnostic siblings. The usage context is implied but not stated.
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=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat the safety profile. The description adds the detail-level options, which are useful, but it does not disclose behavior around missing IDs or failure handling. This is acceptable given the strong annotation coverage.
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 one concise sentence that front-loads the core action and resource, then packs the detail-level variants compactly. There is no filler or redundant explanation.
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 read operation with strong annotations and well-described parameters, the description is nearly complete. It conveys the resource, ID source, and detail levels, though it does not specify the exact return structure for each view. This is a minor gap for such a straightforward retrieval 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 input schema already provides full descriptions for both parameters, including the enum, default, and payload-size explanation for 'view'. The description repeats the view concept but adds little meaning beyond the schema. Baseline 3 is appropriate because schema coverage is high.
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 ('Read') and resource ('one email by envelope ID'), and specifies the available detail levels. It clearly distinguishes the tool from sibling tools like schedule_email and mailbox_delete, which involve different 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?
The main description does not name alternatives, but the parameter description for 'id' provides clear context: this tool is used when an envelope ID has been obtained from search, recent, or thread tools. This gives sufficient usage context, though it does not explicitly state when not to use the 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. It adds value by disclosing a bounded request (limit of 50) and 'per-ID errors', indicating partial failure handling. This goes beyond the annotations and helps the agent predict 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?
The description is a single, compact sentence: 'Read up to 50 emails in one bounded request, with per-ID errors.' It front-loads the core action and includes key constraints efficiently without any filler. Every phrase contributes to understanding.
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 existence of an output schema and thorough parameter documentation, the description covers the essential context: it explains the batch nature, the limit, and error handling. It does not mention what happens if more than 50 IDs are supplied, but the schema's maxItems=50 covers validation. Overall, it's sufficient for an agent to call 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 100% with rich parameter descriptions (e.g., ids 'Envelope IDs returned by search, recent, or thread tools' and view enum with meanings). The tool description does not add meaning beyond the schema, which already explains both parameters adequately. Base score 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 states a specific verb ('Read'), a resource ('emails'), and a distinctive scope ('up to 50', 'one bounded request'), which clearly separates it from siblings like search_emails (searching) or list_recent (listing). It also mentions 'per-ID errors', adding specificity. This is a clear, non-tautological 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 implies a batch operation but does not explicitly state when to use this over get_email (single) or search_emails. It mentions 'bounded request' but lacks explicit guidance on selecting this tool versus alternatives. An agent could infer from the name and 'multiple emails', but explicit when-to-use instructions are absent.
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 cover idempotency and non-read-only behavior, but the description adds that the tool reports live and index verification after creation. This adds behavioral context beyond the structured data and does not contradict the annotations, even though the exact meaning of 'live and index verification' is not expanded.
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 one front-loaded sentence that states the action, the idempotent property, and the verification outcome. Every phrase adds relevant information, with no waste 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?
For a tool with only two required scalar parameters, a detailed schema, and annotations covering idempotency and mutation, the description provides enough context for correct invocation. The main gap is that the verification reporting is not described in terms of a concrete return shape, and error behavior for an invalid account is unspecified.
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 fully documents both account and path, including the nested-folder behavior of slashes. Since schema coverage is high, the description does not need to contribute additional parameter meaning; it is at baseline for this situation.
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 — 'Create a mailbox' — and adds idempotency, which distinguishes this tool from siblings like mailbox_delete and create_draft. The phrase 'report live and index verification' also clarifies what the operation does beyond just creation.
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 is clear this tool is for creating mailboxes, and the idempotency qualifier implies it can be used when a mailbox might already exist. However, the description does not explicitly say when to prefer this over listing mailboxes or other related alternatives, so the usage guidance is implied rather than direct.
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 destructiveHint=true and readOnlyHint=false, so the description does not need to restate that. However, it adds valuable context beyond annotations by specifying the cancellation is 'locally and, when needed, in Exchange', disclosing the conditional scope of the operation. This is additional behavioral information not captured in the schema or 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 a single, front-loaded sentence with no filler. Every word adds value, specifying the action, the target, and the conditional scope. It is concise yet complete.
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 low complexity (one parameter, one action), the presence of an output schema, and annotations covering safety (destructive, idempotent), the description is complete enough for an agent to invoke it correctly. It clearly states what will happen and the scope, with no missing critical information.
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 covers the single parameter 'id' fully (100% description coverage), so the description does not need to add parameter details. It doesn't, and the baseline is 3 given high schema coverage. No additional meaning is provided beyond the schema, but none is required here.
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 states a specific verb ('Revoke'), a specific resource ('pending scheduled email'), and a scope ('locally and, when needed, in Exchange'). This clearly distinguishes it from sibling tools like schedule_email (creating) and list_scheduled (listing). An agent can immediately tell what this tool does without consulting other definitions.
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 (cancel scheduled emails) but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. It does not mention, for example, that it should not be used for already-sent emails. Only implied usage is present, no explicit routing.
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=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds the chronological ordering and the scope of 'one conversation', but doesn't discuss error cases or pagination. With annotations covering safety, 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?
One sentence, under 20 words, states the core action without any filler. Ideal conciseness.
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 read-only tool with a single parameter and a comprehensive schema, the description fully covers what the tool does. The output schema presumably details the return structure, and annotations cover safety. Nothing an agent needs is missing.
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%, and the schema description for thread_id already explains it as 'Conversation ID returned on an email reference.' The tool description adds no further parameter details, so the baseline of 3 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 uses a specific verb ('Return') and resource ('messages in one conversation') and specifies order ('chronological'), clearly distinguishing it from sibling tools like get_email which returns a single email.
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 usage when you have a thread_id from an email reference. However, it does not explicitly contrast with alternatives like get_email or search_emails, so it misses the explicit when-not guidance for a 5.
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 the tool as destructive and non-read-only. The description adds valuable context: 'live verification' (checks emptiness at call time) and 'safe fallback' (presumably aborts if non-empty). This goes beyond the annotation flags, though the fallback mechanism is somewhat vague.
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?
A single 11-word sentence with the core action and constraint front-loaded. Every phrase earns its place, and there is no redundancy or fluff.
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 two-parameter destructive tool with a full input schema and annotation coverage, the description covers the key condition (empty-only) and the safety behavior. The exact behavior of the 'safe fallback' is unspecified, but the output schema likely documents the return value, so this is a minor gap.
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%: both parameters are described in the input schema, including path semantics with slashes and account UUID. The description itself adds no parameter-specific detail, so the baseline of 3 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 states a specific verb ('Delete'), resource ('mailbox'), and a clear precondition ('empty mailbox only'). This distinguishes it from sibling tools like mailbox_create and triage_plan_delete, and the 'empty only' qualifier precisely scopes the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Delete an empty mailbox only' explicitly sets the condition for safe invocation and implies the tool is not for non-empty mailboxes. It doesn't name alternative tools, but no competing mailbox-deletion sibling exists, so the guidance is sufficient for selecting it.
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, idempotentHint, and destructiveHint, so the description only needs to add context beyond that. It does by specifying that the tool returns counts for server and locally readable mailboxes, which is useful but doesn't disclose the full return structure. With annotations handling safety, this adds meaningful context 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?
A single, clear sentence with no filler. The key action and resource are front-loaded, and the additional count detail is 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?
For a simple, parameterless list tool, the description is complete. It covers the purpose and the specific output (counts), and the presence of an output schema means return details need no further explanation. No essential information is missing.
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 baseline of 4 applies. The description correctly has nothing to add about parameters, and the 100% schema coverage (empty properties) confirms no missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'configured mailboxes,' and adds the specific detail that it returns server and locally readable counts. This is distinct from sibling tools like search_emails or get_email, so an agent can easily understand its 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 implies when to use the tool (when you need a list of configured mailboxes) but does not explicitly mention alternatives or exclusions. No sibling tool appears to overlap directly, so the guidance is adequate without being explicit.
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:

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

Score Badge

Copy to your README.md:

[![apple-mail-mcp MCP server](https://glama.ai/mcp/servers/parasxos/apple-mail-mcp/badges/score.svg)](https://glama.ai/mcp/servers/parasxos/apple-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/parasxos/apple-mail-mcp'

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