apple-mail-mcp

by TG-Techie

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.8.1
Disambiguation5/5
Each tool targets a distinct resource and action: templates, drafts, messages, mailboxes, rules, and accounts are clearly separated. The message-related tools (search, get, update, delete, thread, attachments) each have unique purposes, and the draft tools (create/update/delete/send) are unambiguous. No two tools appear to do the same thing.
Naming Consistency3/5
Most tools follow a verb_noun pattern (list_templates, create_rule, get_messages, etc.), but the draft tools use a noun_verb pattern (draft_create, draft_send) and email_send_html also deviates. This inconsistency between subgroups makes the naming less predictable, though each subgroup is internally consistent.
Tool Count4/5
25 tools is above the typical ideal range (3-15) but still appropriate for a comprehensive mail-client server covering messages, drafts, templates, rules, mailboxes, and accounts. Each tool serves a specific purpose, and no tools are redundant, though the large count requires careful organization.
Completeness5/5
The tool surface covers the full lifecycle for all major domains: messages (search, retrieve, update, delete, thread), drafts (create, update, delete, send), templates (list, get, save, delete, render), rules (list, create, update, delete), and mailboxes (list, create, update, delete). There are no obvious gaps that would hinder common workflows.
Average 4.2/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action with no mention of side effects, permission requirements, what happens on duplicate names, or whether the operation is reversible. The description is so minimal that an agent cannot predict consequences beyond the immediate creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no wasted words. It is front-loaded with the core action and resource. It could be slightly more structured (e.g., adding a brief note about nesting), but it is appropriately concise for a simple create operation.
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 is a basic create operation, and the output schema exists, so return values need not be described. However, given the lack of annotations, the description is incomplete in conveying behavioral nuances (e.g., whether parent_mailbox nesting has any special requirements). It is adequate for a simple tool but leaves room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema itself. The description adds no additional parameter semantics beyond what the schema already provides. Per the rubric, this warrants a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new mailbox/folder'), making the tool's purpose immediately understandable. It is specific enough to distinguish from update/delete/list siblings, though it does not explicitly differentiate from other creation tools like create_rule, which is acceptable given the distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. While it is the only create-mailbox tool, the description does not mention prerequisites (e.g., an existing account), when nesting is appropriate, or any conditions that would favor this over updating or deleting a mailbox. The schema covers structure but not 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It states 'overwrite', which implies idempotent replacement, but it does not mention any side effects, authentication requirements, potential data loss, or response behavior. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is appropriately sized for a simple save operation. However, it could be slightly more informative without being verbose, hence a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward create/overwrite operation, the description is minimally sufficient. The presence of an output schema means return values are covered elsewhere. However, given no annotations and no mention of overwrite semantics (e.g., whether it replaces entirely), the description lacks some context that would help an agent understand edge cases. Overall, it is 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%, with each parameter (body, name, subject) having its own description. The tool description adds no extra semantic meaning beyond the schema, which is acceptable given the high coverage. Baseline 3 is appropriate.
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 ('Create or overwrite') and resource ('a template'), making the purpose understandable. It does not explicitly distinguish from sibling tools like get_template or render_template, but the verb clearly implies a save operation, which is distinct from reading, rendering, or deleting. Slight deduction for not naming any sibling to avoid 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?
No guidance is given on when to use this tool versus alternatives. It does not mention that this is for creating new templates or modifying existing ones, nor does it reference any sibling tools. The agent must infer usage from the name and brief description, which is insufficient for a tool with many related operations.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention side effects (e.g., file creation, overwriting), permission requirements, error behavior (e.g., what if the directory doesn't exist), or return value details. The presence of an output schema helps, but the description itself is silent on runtime 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, well-formed sentence with no filler. The verb and object are front-loaded, making it immediately scannable. It is both concise and appropriately structured for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a file-writing operation, the description is too bare. It does not clarify whether the directory must pre-exist, whether attachments are saved with original names, what happens if no attachments exist, or what the output schema represents. Given no annotations and an output schema, the description still leaves significant gaps an agent would need to handle correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all three parameters (100% coverage). The description adds no additional meaning beyond what the schema states; it merely repeats the general idea. Since the schema covers parameters well, a baseline 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 clearly states the action (save attachments), the resource (message), and the target (directory). It is specific and distinct from sibling tools like 'save_template' or 'email_send_html', so an agent can immediately understand what this 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you have a message and want to save its attachments—but provides no explicit context about when to choose this over alternatives or any prerequisites (e.g., needing a message_id from search results). It leaves the agent to infer usage from the schema and name.
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?
With no annotations, the description carries the full burden. It discloses key behaviors: 'Additive — no confirmation prompt' and that it appends to the end of the rule list, explaining that the returned rule_index equals the new total count. This goes beyond what a schema would naturally imply, though it omits details like idempotency or error behavior, so a 4 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 sentences, zero filler. The purpose is front-loaded, and the behavioral note is efficient and directly relevant. Every word earns its place, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral context (additive, append, return semantics) and the schema handles parameter details. Given the tool's moderate complexity (nested objects, output schema), it's complete enough for an agent to call it correctly. An explicit mention of prerequisites or side effects would make it a 5, but this is solid.
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%, meaning every parameter is already documented with types, defaults, and formats in the input schema. The description adds no additional parameter-level detail, so the baseline score of 3 is correct — the schema does the heavy lifting.
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 'Create a new Mail.app rule' — a specific verb and resource. It clearly identifies the tool's action and object, and the term 'new' distinguishes it from update/delete operations. There is no ambiguity about what this 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like update_rule or list_rules. It implies usage for creating rules but never says 'use this when you need a new rule' or contrasts with sibling tools. The only usage-related guidance is 'Additive,' which is more behavioral than contextual.
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?
With no annotations provided, the description carries full responsibility. It discloses that the tool moves the draft to Trash (Deleted Messages), notes no recovery is expected, and specifies it does not send. This offers meaningful behavioral context beyond the bare action, though it does not cover error cases or side effects like what happens if the draft does not exist.
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 primary action and resource, followed by a concise clarification of behavior. Every word contributes value, with no redundancy or filler.
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 one-parameter tool with an output schema, the description covers the core action and behavior. The only minor gap is not mentioning what happens if the draft_id is invalid or missing, but this is likely covered by the output schema (which is present). Overall, adequate 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?
The schema already fully documents the single parameter draft_id with the description 'Existing draft to delete.' The tool description adds no new semantics about the parameter—it just repeats 'existing draft' from the schema. With 100% schema coverage, the baseline of 3 is appropriate since the description does not enhance understanding of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete/move to trash), the resource (draft), and adds specificity ('existing draft') distinguishing it from other delete tools like delete_messages or delete_mailbox. The mention of 'No send, no recovery' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternative delete tools like delete_messages or delete_template. The description implies it is for drafts, but does not explicitly say 'use this instead of delete_messages when targeting drafts' or provide any conditions. The agent must infer from the tool name.
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?
With no annotations, the description must disclose behavioral traits, but it only states that it returns a list of message dicts 'possibly of length 0 or 1'. This is misleading for multiple message IDs, and it fails to mention side effects, cost, or performance considerations. It also doesn't warn about heavy payloads from full details, leaving the agent without critical behavioral expectations.
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 compact (two sentences) and front-loaded with the main purpose. However, the phrase 'possibly of length 0 or 1' is not only ambiguous but also potentially incorrect for multiple IDs, which detracts from an otherwise tightly written definition.
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 the output schema exists and parameter schemas are rich, the description provides useful context on usage and alternatives. However, the misleading return-length statement creates incompleteness, and it does not mention that multiple IDs yield multiple results or that results are partial if some IDs are missing (though the schema does). This leaves the description slightly incomplete.
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 does not add meaning to parameters beyond what the schema already provides. It doesn't compensate for any gaps, but since none exist, the score remains at the 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 verb 'Get', the resource 'messages', and specifies 'full details with bodies'. It explicitly differentiates from siblings by naming 'search_messages' as metadata-only and 'get_thread' as thread member ids, making the tool's unique role 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?
It explicitly pairs with 'search_messages' and 'get_thread' and states that this tool fetches bodies for specific messages, implying when to use it versus alternatives. This gives clear context and a specific condition (need bodies) that selects this tool.
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?
No annotations are provided, so the description carries the full burden. It states 'Read', which implies a non-destructive operation, but it does not disclose additional behavioral details such as error behavior (e.g., not-found), permission requirements, or rate limits. The verb provides minimal transparency but nothing beyond that.
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, dense sentence with no filler: 'Read a single template by name.' The verb leads, the resource and scope are clear, and no word is wasted. Perfectly concise for the simple action it describes.
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 one parameter fully documented in the schema and an output schema that describes the return, the description is nearly complete for a simple getter. It could mention what happens if the template does not exist, but that is a minor gap; the core information needed to call the tool correctly is present.
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 covers 100% of the parameter (name), so the baseline is 3. The description's phrase 'by name' simply restates the parameter meaning without adding new semantics or syntax details beyond what the schema already 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 states a specific verb ('Read'), a resource ('template'), and scope ('single... by name'), clearly distinguishing it from list_templates (which lists all) and template-related siblings like save_template and render_template. The purpose is immediately clear.
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 it (when you need a single template by name), but it does not explicitly state when not to use it or name alternatives. There is no mention of preferring get_template over render_template or list_templates. Usage context is implied but not made explicit.
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?
With no annotations, the description carries the full burden. The verb 'List' implies read-only, but the description does not explicitly state safety, no side effects, or any behavioral expectations beyond the result set. However, the output schema covers return structure, and the operation is inherently safe, so a 3 is reasonable.
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 that states the action, target, and scope with zero 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?
Given the simplicity of the tool, the description, along with a well-documented schema and an output schema, is nearly complete. The only slight gap is not mentioning that 'account' typically comes from list_accounts, but that is already embedded in the parameter description.
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% for the single parameter 'account', and the schema already provides a detailed explanation (display name vs UUID, stability). The tool description adds no extra parameter information, which is acceptable given 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 uses a specific verb ('List') and resource ('mailboxes') with a scope restriction ('for an account'). It clearly distinguishes from sibling tools like create_mailbox, update_mailbox, and delete_mailbox, and the 'all' modifier sets expectations about completeness.
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 (to get mailboxes for a given account) but does not explicitly mention alternatives or when to prefer this over list_accounts. It's clear enough for a simple list operation, but there is no explicit when/why guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the key Trash behavior but omits other important traits, such as the permanent parameter being a no-op, that messages are recoverable from Trash, and that providing account and source_mailbox improves performance. These are only partially covered in the schema, not in the description itself.
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 sentence that front-loads the most important behavioral fact (Trash) with zero waste.
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 that the schema thoroughly documents all four parameters and an output schema exists, the description is minimally sufficient. It captures the core deletion semantics, though it could mention the recoverability aspect or performance hints, but these are already covered by parameter descriptions.
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 itself adds no parameter-specific meaning beyond the schema; the main line is about overall behavior, and parameter details are left entirely to the schema, which is comprehensive.
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') and resource ('messages') and adds a critical behavioral qualifier ('always moves to the account's Trash mailbox'), which clearly distinguishes it from other deletion tools like delete_rule or delete_mailbox 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear context for use by specifying that deletion always results in Trash, which implicitly warns agents not to expect permanent removal. However, it does not explicitly name alternative tools or conditions for when this tool should not be used, though none directly exist for permanent deletion.
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 are absent, so the description carries the burden. It explicitly discloses that the operation is destructive and requires user confirmation via MCP elicitation, which is critical for an agent to know before calling. It does not mention effects like permanence or error handling, but the confirmation warning is substantial.
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 with zero waste. The purpose is front-loaded, and the destructive/confirmation warning follows immediately. 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?
For a simple single-parameter destructive operation, the description covers the essential safety aspect. An output schema exists, so return values need not be described. Minor gaps like error behavior (e.g., what happens if the template doesn't exist) are not covered, but the critical info is present.
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% and the parameter 'name' is fully documented as 'Template name to delete.' The description adds no additional semantic meaning beyond the schema, so 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?
The description states a specific verb ('Delete') and resource ('template') and adds the key scope of matching by name. It clearly distinguishes from siblings like get_template, save_template, and render_template. No 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 description implies usage is for deleting templates but does not explicitly state when to use this versus alternatives (e.g., when not to use, or that get_template might be needed first to confirm the name). No exclusions or alternative routing. Basic guidance only.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it performs well: it details the hard policy gate (allowlist check on all recipients), the block behavior (draft left intact), and the timing guarantee (detection before any destructive operation, so a blocked send is a pure no-op). The only gap is that the success path (what happens to the draft after a successful send) is left implied rather than stated.
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 core purpose is front-loaded in the first sentence, followed by the safety-critical policy gate explanation. Each section earns its place given the eligibility risk. There is modest redundancy at the tail — 'detected BEFORE any destructive operation... pure no-op' partly restates 'left INTACT' — but overall the structure is efficient and well-organized.
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 safety-critical, and the description covers the essential operational context: the allowlist gate, blocked-state behavior, and remediation routes. Given the output schema likely documents return values and the schema covers the single parameter fully, nothing an agent needs to invoke the tool safely is missing. Success-path side effects are the only notable omission.
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%, and the sole parameter draft_id is already well documented in the schema as 'Id of the saved draft to send.' The description adds no additional parameter semantics beyond the schema, so the baseline 3 applies — acceptable given the schema does the heavy lifting.
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 opening sentence 'Send an existing draft' is a specific verb+resource that clearly states the action. It is explicitly differentiated from siblings with 'THIS IS THE ONLY SEND TOOL', which separates it from draft_create, draft_update, and draft_delete in the same family. The naming claim is assertive and gives an agent unambiguous selection criteria.
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 states when to use this tool (to send a saved draft) and, importantly, what to do when the send is blocked — edit via draft_update or handle manually in Mail.app. It provides clear context for the post-block workflow. However, it does not explicitly contrast against email_send_html, a sibling that might be a competing send path, leaving that differentiation 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?
With no annotations, the description carries the full behavioral burden. It discloses that templates are stored as files, gives the default path and the environment variable override, and describes the return format (dictionary with name and subject). This goes beyond just the action and provides useful behavioral context, though it does not explicitly mention read-only nature or edge cases.
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. It front-loads the purpose, then provides storage details and return format in separate lines with clear formatting. Every sentence earns its place without redundancy.
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 there are no parameters and an output schema exists, the description is complete. It explains the storage mechanism, environment override, and the return shape, leaving no critical information missing for an agent to invoke the tool 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?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds context about the environment variable that affects template location, which is not a parameter but relevant operational detail. Since there are no parameters to describe, a baseline of 4 is appropriate and the description does not need to add more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'all stored email templates.' It distinguishes from siblings like get_template by explicitly saying 'all' and 'stored', implying a bulk listing operation rather than individual retrieval.
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 operational context (file storage location, environment variable override) but does not explicitly state when to use this tool versus alternatives such as get_template or render_template. It lacks any when-to-use or when-not-to-use guidance, leaving the agent to infer the appropriate 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?
With no annotations, the description carries the full burden. It discloses key behavioral traits: the email is composed via clipboard injection into Mail.app's rich-text compose window and sent immediately, plus the outbound allowlist policy. This goes beyond typical stub descriptions and provides operational context an agent needs.
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?
Three concise sentences with no redundant wording. The main action is front-loaded, followed by critical behavioral notes and policy constraints. Every sentence 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 description covers essential operational details: direct send, clipboard injection mechanism, immediate sending, and allowlist policy. It omits failure handling or return details, but an output schema exists, so return behavior need not be in the description. For a mutation tool with no annotations, this is reasonably 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 coverage is 100%, so all parameters are already described in the input schema. The description does not add parameter-specific details beyond the schema; it only reiterates that the body must be an HTML string, which is already in the schema. 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?
States a specific verb and resource: 'Send an HTML email directly.' It further clarifies 'Does not save a draft first,' which distinguishes it from draft-related siblings like draft_send and draft_create. The scope is clear 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 explains the primary use case (direct send without draft) and implies this is the go-to for immediate sending. However, it does not explicitly name alternatives or state when not to use it, such as 'use draft_send to send an existing draft.' The context is useful but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the internal threading dispatch strategies (Tier 1/3 IMAP and AppleScript), the sorting order (date_received ascending), and a known limitation (missing rewritten subjects on AppleScript). It does not explicitly state read-only behavior, but the 'get' verb and lack of side-effect language imply safety. Informative and honest.
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 dense but efficient. It front-loads the core purpose, then explains the mechanism, provides downstream usage, and ends with a relevant limitation. Every sentence serves a purpose and there is no filler. Well-organized in three short paragraphs.
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?
With an output schema present, the description need not detail return values. It covers what the tool does, how it works, sorting, downstream usage, and a known limitation. For a single-parameter read-only operation, this is complete and leaves no obvious gaps for an agent 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?
Schema coverage is 100%, so the parameter is fully described. The description's mention of 'anchor message' restates the schema's 'any message in the thread' without adding new constraints or format details. It adds minimal value beyond the schema, so a 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?
The description begins with a specific verb-resource pair ('Return all messages in the thread') and immediately clarifies the input condition ('containing the given message'). It goes further to explain the internal lookup and reconstruction strategy, which clearly distinguishes it from siblings like get_messages or search_messages. The mention of pipable ids to other tools reinforces its distinct role.
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 clear context: use this to get the full thread when you have any message id. It explicitly suggests how the returned ids can be used with search_messages and get_messages, implying alternatives for metadata or body retrieval. However, it does not explicitly state when NOT to use this tool (e.g., if you only need a single message), which prevents 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?
With no annotations provided, the description carries the full burden. It discloses the read-only nature, that rule names are not guaranteed unique (Mail allows duplicates), and that rules have no stable id via AppleScript. It also provides a concrete return example. It does not cover potential errors or edge cases, but for a simple read-only list this is a solid 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 clear and front-loaded with the core purpose. The duplicate-name caveat and read-only note are useful. The example clarifies the return shape without excessive verbosity. It could be slightly tighter by merging the 'Returns' line into the example, but overall it is efficient.
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, read-only list tool, the description covers the essential domain information: what it returns, the uniqueness caveat, and the mutation separation. It does not address error conditions or the absence of an id field, but these are minor for this simple operation. The presence of an output schema (via example) further reduces the burden. Overall it is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Per rubric, 0 params gives a baseline of 4. The description adds no parameter-specific meaning because none exist, and none is needed.
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?
Begins with 'List all Mail.app rules' — a specific verb and resource. The read-only qualifier immediately distinguishes it from mutation siblings like create_rule/delete_rule/update_rule. The description fully identifies the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'This tool is read-only; mutation (enable/disable, create, delete) is tracked as a separate enhancement,' which clearly signals when not to use this tool. However, it does not explicitly name the alternative sibling tools (create_rule, update_rule, etc.), relying on the agent to infer from the sibling list. Still, the context is clear enough for correct selection.
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?
With no annotations provided, the description carries full burden. It explicitly states 'No side effects,' discloses auto-fill behavior (recipient_name, recipient_email, etc.), and the precedence rule 'User-supplied vars always override auto-fills on conflict.' This covers the main behavioral traits an agent needs, though it omits error handling or edge cases.
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 approximately 90 words across three paragraphs, with each sentence contributing value. It front-loads the primary purpose, then side-effect caveat, then parameter behavior. No redundancy or filler; 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 tool has an output schema, so return values need not be described. The description covers purpose, side effects, parameter semantics, and next steps. It does not mention error conditions (e.g., missing template), but given the output schema and other disclosures, it is largely complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond the schema. It explains exactly how message_id triggers auto-population of four variables and how vars interact with auto-fills, including the override precedence. This is critical semantic information not present in the parameter descriptions.
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 it 'Render a template into ready-to-send subject and body text.' This specifies the verb (render), resource (template), and output. It does not explicitly contrast with sibling tools like get_template or save_template, but 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'No side effects — caller is responsible for passing the rendered text to create_draft or update_draft.' It also explains when message_id is useful. However, it does not explicitly state when not to use this tool or name alternatives, relying on implicit understanding from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (a dictionary with success and accounts list), the structure of each account (id, name, email_addresses, account_type, enabled), and the stability of IDs as an important behavioral trait. It includes a concrete example, which adds transparency. It does not cover failure cases or rate limits, but for a simple read-only list, this is reasonable.
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 reasonably concise but includes a detailed example and a note on ID stability. It is structured with a clear main sentence, a returns section, and an example. It avoids fluff and front-loads the core purpose, with additional useful context embedded. It could be slightly shorter but is well-organized.
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 zero-parameter listing tool, this description is complete. It states exactly what it returns, the structure of each account, and provides a realistic example. The ID stability note is a valuable extra that helps downstream selection. The presence of an output schema (indicated by context signals) further reduces the need to explain return details, but the description already covers them. Nothing critical is missing for an agent to call this tool 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?
The input schema is empty (zero parameters), so there is nothing to explain. The description does not need to clarify parameter usage. The baseline for zero parameters is 4, and the description adds no irrelevant parameter info, so this 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 and resource: 'List all configured email accounts in Apple Mail.' It clearly differentiates from siblings like list_templates, list_rules, and list_mailboxes by resource type. The uniqueness is unambiguous given the sibling list, so an agent can identify this tool 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to prefer account IDs over names ('Account ids are stable across name changes; prefer them over names for identifying accounts'), which is useful for downstream operations. However, it does not explicitly state when to use this tool versus alternatives, but the alternatives are clearly different resources, so the context is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is destructive, requires user confirmation via MCP elicitation, and cannot be undone because Mail.app does not version rule history. These are critical operational traits that an agent must know before calling, and they are clearly articulated.
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, with the purpose statement first and the safety/irreversibility warning second. Every word is necessary; there is no fluff or repetition. The front-loading of the action makes it immediately scannable.
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 (one parameter) and the presence of an output schema, the description covers all essential aspects: the action, the index requirement, the destructive nature, and irreversibility. An agent can correctly call this tool with the information provided, including knowing to obtain the index from list_rules (implied by the schema description). Nothing critical 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?
The input schema already describes the single parameter as '1-based positional index from list_rules' with 100% coverage. The tool description merely repeats the same information ('by 1-based positional index') without adding new semantics. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a Mail.app rule' with a specific method ('by 1-based positional index'). The verb and resource are unambiguous and distinguish it from sibling tools like delete_mailbox or delete_template. The mention of 'Mail.app' and 'rule' makes the target explicit.
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 conditions: it requires a 1-based index (which must come from list_rules) and mandates user confirmation before running. It does not explicitly name alternatives or when-not conditions, but the unique scope (Mail.app rule) and the destructive nature give sufficient context for an agent to decide when to invoke it. It could benefit from an explicit 'use after list_rules' note, but the schema parameter description already covers that.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals atomic execution, the bulk-update helper, the IMAP ordering constraint, and even mentions a 'narrow-path optimization' with source_mailbox. It does not mention idempotency or error handling, but the atomicity and ordering are well covered.
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 main purpose is stated in the first sentence, then the patch semantics and order of operations follow in clear, short paragraphs. There is no filler; every sentence adds necessary context for correct invocation.
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 complexity (8 parameters, atomic batch update, IMAP constraints, and replacement of three prior tools), the description covers all critical aspects: what it does, when to use it, how it behaves atomically, and the order of operations. An output schema exists, so return values are not the description's responsibility. No essential information for an agent to call the tool correctly 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?
The input schema already provides 100% coverage, describing each parameter and their interplay (e.g., 'flag_color implies flagged=True unless none'). The description adds patch semantics as a general principle, but does not enrich individual parameter meaning beyond the schema. The baseline of 3 is appropriate because the schema does the heavy lifting.
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 starts with a precise verb-resource pairing: 'Update one or more messages: change read state, flag, and/or move, in one atomic call.' It enumerates the exact operations and states it is atomic. It also explicitly distinguishes itself from prior separate tools by naming them and saying it replaces them.
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 guidance: it lists the three legacy tools it replaces, so an agent knows to prefer this consolidated tool. It also explains patch semantics ('caller specifies only the fields to change') and gives operational order ('read-state and flag changes apply first, then the move'), which is essential for correct IMAP usage.
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?
With no annotations provided, the description alone must convey the destructive nature and error behavior. It does so thoroughly: confirmation always required, default refusal of non-empty mailboxes, precise error_type values for missing credentials and Gmail path restrictions. This is exemplary disclosure of side effects and edge-case behavior.
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 longer than typical but every sentence serves a purpose: technical rationale, prerequisite, safety behavior, and special-case rejection. It is logically organized into paragraphs with the core purpose first. Slightly more verbose than necessary but well-structured and free of 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?
Given the tool's complexity (destructive, requires credentials, special Gmail behavior) and lack of annotations, the description leaves nothing essential uncovered: usage, errors, safety, and constraints are all present. The presence of an output schema means return-value documentation is not required here. Complete 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?
The input schema covers 100% of parameters with clear descriptions (name, account, delete_messages). The description adds slight nuance to delete_messages by explaining the cascade effect, but this is already implied in the schema's description. Baseline 3 is appropriate since the schema carries the explanatory load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action on a specific resource ('Delete a mailbox via IMAP') and immediately differentiates from the built-in Mail.app primitive by explaining why IMAP is used. The acronym IMAP and the mention of Mail.app's AppleScript limitation make the tool's scope unmistakable and distinct from sibling message-deletion tools.
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 explicit preconditions: requires IMAP credentials, returns a specific error when missing. It also states the tool always elicits user confirmation, refuses non-empty mailboxes unless cascade is requested, and lists the unsupported Gmail system-label paths. These are clear 'when and when-not' directives that an agent can act on without guessing.
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?
With no annotations provided, the description carries the full disclosure burden. It thoroughly covers error types (imap_required, unsupported_gmail_system_label, validation_error), special cases for Gmail system labels, and path-traversal sanitization. It doesn't explicitly state that the operation is non-destructive to the mailbox content, but the rename/move semantics are implicit. This is strong coverage.
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 longer than most, but it is well-structured with clear headings and bullet points, and the core purpose is front-loaded. Every sentence carries necessary information about behavior, errors, or conditions. It could arguably be tightened, but the density of essential details justifies the length.
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 moderate complexity (two delivery paths, authentication requirements, Gmail restrictions), and the description addresses all of these thoroughly. It explains parameter combinations, error scenarios, and prerequisites. Although there is an output schema, the description still covers the necessary contextual and prereq info an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial value beyond the schema: it explains the interplay between new_name and new_parent, the None defaults, the top-level move via empty string, and the sanitization behavior. The description resolves ambiguities that the schema alone would leave, such as what happens when both are null (error) and how Gmail paths are treated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: rename and/or re-parent an existing mailbox. Clearly distinguishes from siblings like create_mailbox and delete_mailbox by focusing on modification. The first sentence 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains two delivery paths (rename vs move) with conditions on which parameters to set, the requirement that at least one be provided, and the IMAP credentials prerequisite for moves. Also clarifies unsupported Gmail paths with actionable error responses, so an agent knows exactly when to use rename vs move and what to expect.
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?
With no annotations, the description carries the full burden and does so thoroughly. It discloses patch semantics, wholesale replacement of conditions/actions, irrecoverable replacements, the confirmation prompt logic, and the specific error (MailUnsupportedRuleActionError) for unsupported actions. This is exemplary transparency.
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 dense but not bloated; every sentence adds value. It leads with purpose, then patch semantics, then confirmation, then the tool replacement, then error conditions. The length is justified given the complexity, though it could be slightly tighter. Still, structure and front-loading are excellent.
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 complex mutation tool with no annotations but an output schema, the description covers all critical aspects: patch behavior, confirmation triggers, error cases, and the migration path from set_rule_enabled. Nothing essential is missing for an agent to call 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?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: it explains that conditions and actions are replaced wholesale (vs. merged), ties match_logic to confirmation prompting, and identifies reversible vs. irrecoverable fields. This elevates the semantics beyond mere 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?
States a specific verb ('Update') and resource ('existing Mail.app rule') with patch semantics, immediately distinguishing it from siblings like create_rule and delete_rule. The description also clarifies the enable/disable path, reinforcing the tool's scope.
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 explicit guidance on when to use the tool, including the replacement of set_rule_enabled and the refusal condition for unsupported actions (with instruction to edit via UI). It also clarifies conditional confirmation behavior, giving agents clear decision criteria for invocation.
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?
No annotations are given, so the description carries the full burden. It candidly discloses that the tool does not send, that sending requires a separate explicit action with policy enforcement, and reveals the auto-derivation behavior for reply/forward (recipients and subject prefixes). This goes well beyond the schema and alerts the agent to the critical side-effect boundary.
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 well-structured and efficient: a clear one-line purpose, a note on the sending split, and bullet points for the three modes. The 'DOES NOT SEND' warning and the call to draft_send are front-loaded, ensuring the agent sees the most critical behavior first. No filler or redundancy.
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 complexity (12 params, all optional, output schema present), the description is remarkably complete. It covers the key behavioral nuances for all three modes, explicitly warns about the sending split and policy enforcement, and names the sending tool. The schema provides descriptions for many parameters, and the output schema handles return values, so no critical 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 description adds meaningful context beyond the schema: it explains how reply_to/forward_of drive mode selection, that subject is required for fresh drafts, and that forward drafts default to empty recipients. The schema already covers many parameters with descriptions, and the description complements rather than repeats. A minor gap is no mention of template parameters, but that is not central.
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: it creates a draft (fresh, reply, or forward) and immediately clarifies that it does NOT send. It explicitly names the sibling draft_send as the separate sending step, which distinguishes it from that tool. The three modes are clearly explained via reply_to and forward_of, making the tool's function unmistakable.
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 the tool (to create a draft) and when not to (do not send; call draft_send separately). It explains the intentional split and that sending is the only path where the outbound allowlist policy is enforced. It also details the mode selection logic based on reply_to/forward_of and names the alternative tool draft_send.
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?
With no annotations, the description carries the full burden and discloses critical behavioral traits: it is implemented as delete-and-recreate, the returned draft_id is new, and the original id becomes stale. It also states the patch semantics (None=keep, empty=clear) and that it does NOT send. This is thorough and goes well beyond any structured metadata.
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 efficiently written—three short paragraphs, each serving a distinct purpose: stating the action, defining patch semantics, and alerting about the destructive implementation. It is front-loaded with the core message and every sentence adds value without redundancy.
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?
Despite the tool's complexity (10 parameters, nuanced behavior), the description covers all essential aspects an agent needs: the operation, the patch semantics, the send alternative, and the critical side effect of a new draft_id. The presence of an output schema handles return-value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a universal semantic for all optional parameters: 'only fields you pass change. None means keep existing; empty list/string means clear.' This compensates for the 50% schema description coverage and gives clear meaning to fields like template_name and template_vars that lack schema descriptions. The explicit attachment override behavior (None=keep, []=clear, list=replace) is also reflected.
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 precise verb and resource: 'Update an existing draft' and immediately clarifies the scope with 'DOES NOT SEND.' This cleanly distinguishes it from sibling tools like draft_send and draft_create, leaving 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool versus alternatives: it is for updating drafts, not sending. It even points to draft_send(draft_id) as the follow-up call, giving a clear context for use and excluding the sending scenario. The delete-and-recreate note also signals when this tool is necessary despite its side effects.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure and exceeds it. It reveals that results are metadata-only, that missing ids drop out silently (partial results), that body_contains on AppleScript is slow (with measured times) and adds a warnings field, and that include_attachments is opt-in for performance reasons. It also explains the semantics of the SELECTED sentinel and mixed lists, leaving little to inference.
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 long but every sentence earns its place given the tool's complexity (14 parameters, two modes, performance tradeoffs). It is front-loaded with the core purpose, then uses structured bullet points for the modes, and closes with routing guidance. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent to call this tool correctly. It covers all operational modes, parameter interactions, performance caveats, and even cross-references sibling tools for the right follow-up call. The existence of an output schema means the return format is already established, and the description's note that rows are metadata-only aligns with that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema covers 100% of parameters, the description adds substantial meaning beyond the schema. It explains the two semantic modes of source, the interaction between account/mailbox and source, the approximation of text_contains on AppleScript, and the performance implications of body_contains and include_attachments. This is far beyond the schema's basic property 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 a specific verb ('Search for messages'), a clear resource scope, and clarifies that it returns 'metadata-only rows.' It explicitly distinguishes itself from siblings like get_thread and get_messages by explaining the thread-retrieval pipeline, so an agent can immediately tell which tool to use.
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 gives explicit when-to-use guidance: it contrasts the two source modes (None vs. id list), explains when account/mailbox are required vs. ignored, and routes the agent to get_thread for thread expansion and get_messages for body retrieval or cheap attachment metadata. It also notes when include_attachments should be avoided and when to prefer the alternative.
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/TG-Techie/apple-mail-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TG-Techie/apple-mail-mcp)

Score Badge

Copy to your README.md:

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

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