Apple Mail MCP

by imdinu

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Multiple tools have overlapping purposes that could cause confusion. get_emails, get_flagged_emails, get_todays_emails, and get_unread_emails all retrieve emails with different filters, but their boundaries are unclear—an agent might struggle to choose between them when multiple criteria apply. The descriptions help somewhat, but the functional overlap is significant.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout (e.g., get_emails, list_accounts, search_emails). All tools use snake_case with clear, descriptive names that align with their functions, making the set predictable and easy to understand.
Tool Count5/5
With 7 tools, the count is well-scoped for an email management server. Each tool serves a distinct, useful purpose in the domain (e.g., retrieving emails, listing accounts/mailboxes, searching), and none feel redundant or missing in terms of quantity for the apparent scope.
Completeness2/5
There are significant gaps in the tool surface for email management. The server lacks essential CRUD operations like creating, sending, updating (e.g., marking as read/unread), or deleting emails, which are core to the domain. This will likely cause agent failures when trying to perform common email tasks beyond retrieval and listing.
Average 4.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 10 of 13 community issues answered or closed in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on July 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it returns a sorted list of emails with a default limit, which is useful behavioral context. However, it doesn't mention potential side effects, error conditions, or authentication requirements, leaving gaps for a tool that interacts with mail systems.
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 well-structured with clear sections (Args, Returns, Example) and front-loaded purpose. It's appropriately sized, though the example could be slightly more concise. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has output schema), the description is fairly complete. It covers parameters thoroughly and includes an example, though it could benefit from more behavioral context (e.g., error handling). The output schema existence means return values don't need explanation in the description.
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 schema description coverage is 0%, so the description must compensate fully. It does this by explaining all three parameters: 'account' (with env var fallback), 'mailbox' (with env var fallback and default), and 'limit' (with default value). This adds crucial meaning beyond the bare 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 clearly states the verb 'Get' and resource 'flagged emails from a mailbox', making the purpose explicit. It distinguishes from siblings like 'get_emails' or 'get_unread_emails' by specifying 'flagged' emails, though it doesn't explicitly contrast them in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_emails' or 'get_unread_emails'. It mentions default behaviors for parameters but doesn't explain the tool's specific use case context or prerequisites.
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 describes the return format and includes an example, which adds value beyond basic functionality. However, it doesn't cover aspects like error handling, performance implications, or authentication needs, leaving some behavioral traits unspecified.
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 appropriately sized, with a clear purpose statement, parameter explanation, return details, and an example—all in a concise format. Each sentence adds value without redundancy, making it easy to scan and understand.
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 low complexity (1 parameter) and the presence of an output schema (implied by the return description), the description is fairly complete. It covers purpose, parameter usage, and return format with an example. However, it could improve by addressing sibling tool differentiation or more behavioral details, but it's adequate for the context.
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 has 0% description coverage, but the description compensates by explaining the 'account' parameter's semantics, including its optional nature and default behavior using environment variables. This adds meaningful context beyond the schema, though it could be more detailed about format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('all mailboxes for an email account'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_accounts', which lists accounts rather than mailboxes, though this distinction is implied by the resource focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning the default behavior when the 'account' parameter is not specified, but it doesn't explicitly state when to use this tool versus alternatives like 'get_emails' or 'search_emails'. The implied usage is for listing mailboxes rather than emails, but no clear exclusions or comparisons are given.
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 effectively describes the return format (list of dictionaries with 'name' and 'id' fields) and includes an example, which adds useful context. However, it lacks details on potential errors, permissions needed, or any side effects, leaving some behavioral aspects unspecified.
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 front-loaded, starting with the core purpose, followed by return details and an example. Every sentence earns its place by providing essential information without redundancy. The example is concise and illustrative, enhancing clarity without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, but with an output schema implied by the return description), the description is largely complete. It covers purpose, output format, and includes an example. However, it could improve by addressing potential edge cases or linking to sibling tools for broader context, though the output schema coverage reduces the need for extensive detail.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on output and examples. This meets the baseline for tools with no parameters, as it avoids unnecessary repetition and adds value through output clarification.
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 resource ('all configured email accounts in Apple Mail'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like list_mailboxes (which lists mailboxes rather than accounts) and various email-fetching tools, establishing clear differentiation.
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 by specifying what it returns (account dictionaries), but does not explicitly state when to use this tool versus alternatives like list_mailboxes or other email-related tools. No guidance is provided on prerequisites, exclusions, or comparative contexts, leaving usage somewhat inferred rather than clearly defined.
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 key behavioral traits: it retrieves emails with specific properties, uses environment variable defaults, sorts by date (newest first), and returns a list. However, it does not mention potential errors, rate limits, or authentication needs, leaving some gaps.
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 appropriately sized: a brief purpose statement, details on properties and parameters, return format, and an example. Every sentence adds value without redundancy, and it is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema (implied by 'Has output schema: true'), the description is largely complete. It covers purpose, parameters, returns, and an example. However, it could improve by addressing sibling tool differentiation or error handling, but the output schema likely handles return values adequately.
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 description coverage is 0%, so the description must compensate. It fully explains all three parameters (account, mailbox, limit) with semantics, default values, and usage context (e.g., env var fallbacks). This adds significant value beyond the bare schema, making parameters clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get emails from a mailbox' with specific verb ('Get') and resource ('emails'). It distinguishes from siblings like 'get_flagged_emails' or 'get_unread_emails' by indicating it retrieves emails with standard properties, though it could be more explicit about the distinction.
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 by specifying default behaviors (e.g., using environment variables or defaults for account/mailbox) and the limit parameter, but does not explicitly state when to use this tool versus alternatives like 'search_emails' or 'get_todays_emails'. It provides context but lacks explicit guidance on tool 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 and adds valuable behavioral context: it specifies case-insensitive search in subject and sender fields, default values for account/mailbox via environment variables, sorting by date (newest first), and a default limit of 50 results. This covers key operational traits beyond basic functionality.
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 appropriately sized: a clear opening statement, followed by search scope details, parameter explanations, return info, and an example. Each sentence adds value without redundancy, and information is front-loaded with the core purpose stated first.
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 no annotations and 0% schema coverage, the description provides substantial context: it explains parameters, behavior, and includes an example. However, it doesn't mention error handling, permissions, or rate limits, which could be relevant for a search tool. The output schema exists, so return values needn't be detailed, but some operational caveats are 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?
Schema description coverage is 0%, so the description must compensate. It fully explains all 4 parameters: query (search term), account (with env var fallback), mailbox (with env var fallback), and limit (default 50). This adds crucial meaning beyond the bare schema, detailing defaults and environmental dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for emails matching a query string, specifying the verb 'search' and resource 'emails'. It distinguishes from siblings by mentioning query-based searching, unlike tools like get_emails or get_unread_emails which likely fetch without filtering. However, it doesn't explicitly contrast with all siblings (e.g., get_flagged_emails).
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 query-based email searches, with an example showing a specific use case. It doesn't explicitly state when to use this tool versus alternatives like get_emails or get_unread_emails, nor does it mention exclusions or prerequisites. The context is clear but lacks explicit guidance on 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?
With no annotations provided, the description carries full burden. It discloses the sorting behavior ('sorted by date newest first') and return format ('List of today's emails'), which is valuable. However, it doesn't mention permissions needed, rate limits, pagination, or what happens with invalid account/mailbox values.
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?
Well-structured with purpose statement, parameter explanations, return description, and example. Every sentence earns its place. The information is front-loaded with the core purpose first, followed by details.
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 2 parameters with 0% schema coverage and an output schema exists, the description does an excellent job explaining parameters and return behavior. However, as a read operation with no annotations, it could benefit from mentioning safety (non-destructive) or error handling for completeness.
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 description coverage is 0%, so the description must compensate fully. It provides detailed semantics for both parameters: account (defaults from env var or first account) and mailbox (defaults from env var or 'Inbox'). The example further clarifies usage. This adds significant value beyond the bare 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 clearly states the tool's purpose with specific verb ('Get'), resource ('all emails received today'), and scope ('from a mailbox'). It distinguishes from siblings by focusing on today's emails only, unlike get_emails (general), get_flagged_emails, get_unread_emails, or search_emails.
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 about when to use this tool (for today's emails), but doesn't explicitly state when not to use it or name alternatives. It implies usage for today's emails but doesn't compare with siblings like get_emails (date-range) or search_emails (keyword-based).
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 and does well by disclosing key behaviors: it's a read operation (implied by 'Get'), describes sorting behavior ('sorted by date newest first'), mentions environment variable fallbacks, and provides a concrete return example. However, it doesn't mention rate limits, authentication needs, or error conditions.
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?
Perfectly structured with clear sections: purpose statement, Args with detailed explanations, Returns specification, and Example. Every sentence adds value, with no wasted words. The information is front-loaded and efficiently 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?
Given the tool's moderate complexity, no annotations, and the presence of an output schema, the description provides excellent completeness. It covers purpose, all parameters with their semantics and defaults, return format, sorting behavior, and includes a practical example. The output schema handles return value details, so the description focuses on operational context.
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?
With 0% schema description coverage, the description fully compensates by explaining all three parameters in detail: account (with env var fallback logic), mailbox (with env var and default logic), and limit (with default value). The Args section adds substantial meaning beyond the bare 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 clearly states the specific action ('Get unread emails') and resource ('from a mailbox'), distinguishing it from siblings like get_emails (all emails) or get_flagged_emails (different filter). The verb+resource combination is precise 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 implies usage context through the 'unread' filter and default behaviors, but doesn't explicitly state when to use this tool versus alternatives like search_emails or get_todays_emails. It provides clear default values and environment variable fallbacks, giving practical guidance.
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

Apple Mail MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Apple Mail MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/imdinu/apple-mail-mcp/badges/card.svg)](https://glama.ai/mcp/servers/imdinu/apple-mail-mcp)

Score Badge

Copy to your README.md:

[![Apple Mail MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/imdinu/apple-mail-mcp/badges/score.svg)](https://glama.ai/mcp/servers/imdinu/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/imdinu/apple-mail-mcp'

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