Apple Mail MCP
Productivity · tested 2026-08-21 · re-test due 2026-11-21 · by the Hlido desk, not the vendor
In short: The Apple Mail MCP server that actually searches your whole mailbox — full-coverage FTS5 body search that stays fast on ~73K messages where AppleScript-based servers time out, with honest competitive benchmarks.
4 PASS · 0 FAIL of 4 public-surface claims
Quick answer
Apple Mail MCP scores 75/100 (STEADY) on Hlido’s independent, hands-on test (reviewed 2026-08-21). STEADY (75 — top of this batch) for a well-engineered Apple Mail MCP server that competes on the right axis (full-mailbox FTS5 body search) and backs it with concrete, falsifiable, competitively-benchmarked numbers rathe
Apple Mail MCP is a refreshingly evidence-led tool: an MCP server (and standalone CLI) with eight tools for reading, searching and extracting email, whose headline claim is full-coverage FTS5 full-text body search across the entire mailbox. What earns trust is that the maintainer benchmarked it against six other Apple Mail MCP servers on a real ~73K-message mailbox and reports specifics — only server with full-coverage body search (a named competitor caps at the 5000 most recent messages, silently missing older mail), ~3ms single-email fetch via disk-first .emlx reading, ~7ms subject search via FTS5, and reliability across all six benchmarked operations where AppleScript/JXA servers time out or throw. That is exactly the kind of concrete, falsifiable claim-making Hlido rewards. It's clean on the agent surface too: pipx run for zero-install, a one-line Claude Desktop config, CLI parity for every tool, a --watch flag for live index updates, and a py.typed type-safe codebase (v0.4.3, 56 stars). The honest caveats: the benchmarks are self-run (not third-party), it's macOS/Apple-Mail-only by nature, and real-world performance depends on mailbox shape. For anyone giving an AI assistant access to Apple Mail, this is a well-engineered, honestly-marketed choice.
Why STEADY
STEADY (75 — top of this batch) for a well-engineered Apple Mail MCP server that competes on the right axis (full-mailbox FTS5 body search) and backs it with concrete, falsifiable, competitively-benchmarked numbers rather than adjectives — plus a clean agent surface (8 tools, CLI parity, pipx, --watch, type-safe). Not higher because the benchmarks are self-run rather than independently verified, it's inherently macOS/Apple-Mail-only, and real performance is mailbox-dependent. Not lower because the evidence-led presentation and engineering detail are notably above the norm for a single-maintainer tool.
Public-surface checklist
- PASS Homepage loads (required)
- PASS Primary value prop (required) — The Apple Mail MCP server that actually searches your whole mailbox — full-cover
- PASS Cta present
- PASS Evidence or demo — 4 screenshot(s) captured
What we saw
4 screenshots captured by the Hlido engine during the reviewed run (run-7738c8e50fb37e83-imdinu-github-io). Our own captures — not vendor marketing material.
What it does well
- Full-coverage FTS5 full-text body search across the entire mailbox — where a named competitor caps at the 5000 most recent messages (silent miss on older mail)
- Concrete, competitively-benchmarked performance on a real ~73K-message mailbox: ~3ms email fetch (disk-first .emlx), ~7ms subject search, reliable across all six operations
- Eight MCP tools with full CLI parity (search/read/list/extract), unified filters (unread/flagged/today/last-7-days), --watch live indexing
- Low-friction, type-safe engineering: pipx run zero-install, one-line Claude Desktop config, PEP 561 py.typed, v0.4.3
- Can generate a Claude Code skill for CLI access (apple-mail-mcp integrate claude) — thoughtful agent ergonomics
What it fails at
- Benchmarks are self-run by the maintainer, not independently verified
- macOS / Apple Mail only by nature — no cross-platform reach
- Real-world speed and index-build time depend on mailbox size/shape, which vary widely
- Single-maintainer project (56 stars, v0.4.x); long-term maintenance is unproven
Red flags
- The performance and coverage advantages are self-benchmarked, not independently verified — credible and specific, but confirm on your own mailbox size before depending on them.
- Giving any tool full read access to your mailbox is sensitive; review scope and run locally.
Best for
- macOS users who want an AI assistant to reliably search and read their full Apple Mail history
- People with large mailboxes where AppleScript-based Mail MCP servers time out or miss older mail
- Developers who want the same tools as an MCP server AND a standalone CLI, with live index updates
Not recommended for
- Non-macOS / non-Apple-Mail users
- Teams that require third-party-verified performance claims before adoption
- Users needing send/compose or full mail-management (this is read/search/extract-focused)
Related agents
Agent relevance
CLI MCP Behavioral-testable
Agentic-Commerce Readiness 63/100 · INTEGRABLE
Independent readiness for agent delegation & transaction. How it’s scored · check live
MCP server with eight tools plus full CLI parity; pipx run for zero-install and a one-line Claude Desktop config. Can emit a Claude Code skill for CLI access. Fully local and directly testable, with a --watch flag for live index updates — a clean, agent-native Apple Mail surface.
Agent-friendly score: 9/10
Score over time
The longitudinal record — every point is the score as published on that date. Raw series.
Evidence
- Apple Mail MCP server with full-coverage FTS5 body search; 8 tools; also a standalone CLI; v0.4.3 — source (2026-08-21) verified
- Benchmarked against 6 other Apple Mail MCP servers on a real ~73K-message mailbox; only one with full-coverage body search — source (2026-08-21) verified
- ~3ms single email fetch (disk-first .emlx), ~7ms subject search via FTS5, reliable across all 6 operations — source (2026-08-21) verified
- pipx run zero-install; one-line Claude Desktop config; --watch live indexing; PEP 561 py.typed — source (2026-08-21) verified
- CLI parity for all tools and can generate a Claude Code skill (apple-mail-mcp integrate claude) — source (2026-08-21) verified



