Why mxr
mxr is for people who want their email runtime on their own machine.
That puts it in a different spot from a classic terminal client and a different spot from a hosted connector layer.
The rough map
There are a few overlapping categories here:
- Classic terminal mail clients: mutt, neomutt, aerc
- CLI-first mail tools: himalaya, gog, gws
- Local indexing tools: notmuch
- Hosted connector layers: Nylas CLI, Composio, Zapier MCP, EmailEngine
- Local runtime and bridge experiments: Post,
email-mcp
mxr borrows ideas from all of them, but the center of gravity is simple: local store, local search, daemon-backed workflow, broad CLI surface.
What earlier tools are good at
| Tool | Good fit when you want… | Less central there |
|---|---|---|
| mutt / neomutt | a long-established keyboard mail workflow | local daemon + broad JSON CLI |
| aerc | a modern terminal UI | daemon-backed local runtime |
| himalaya | a clean CLI-first mail client | shared daemon/state layer |
| notmuch | local indexing over existing local maildirs | provider sync + mutations under one tool |
| gog / gws | Gmail scripting | provider-agnostic mail workflow |
| mxr | one local runtime for TUI, CLI, scripts, and agents | hosted connector orchestration |
That is not a knock on the older tools. It is the point. mxr exists because those tools proved the value of keyboard mail, local indexing, and scriptable mail.
Hosted connectors and nearby projects
| Tool | Better fit when you need… | mxr difference |
|---|---|---|
| Nylas CLI | managed provider access with a hosted layer | mxr keeps runtime and state local |
| Composio | cross-app automation with managed auth | mxr stays mail-first and local |
| Zapier MCP | a hosted action layer across many apps | mxr is a local mail runtime, not a SaaS router |
| Gmail MCP servers | Gmail-specific agent access | mxr aims for a broader local mail workflow across providers |
| EmailEngine | a self-hosted email API for backend systems | mxr is aimed at local human + agent workflows |
| Post | a local mail daemon + CLI on macOS | mxr is a Rust codebase with Gmail/IMAP/SMTP focus |
email-mcp | local MCP access to IMAP/SMTP | mxr is broader than the MCP bridge alone |
Hosted connector layers are good fits when you want remote workflows, managed auth, or one endpoint across many SaaS products. mxr is a better fit when you want the mail system itself on your machine.
Choose mxr if…
- You want synced mail in SQLite on your machine.
- You want one tool that works as TUI, CLI, script target, and agent surface.
- You care about search, batch operations, exports, and local workflows.
- You want provider adapters behind one internal model.
Choose something else if…
- You want a hosted connector layer more than a local mail runtime.
- You mainly want a terminal UI and do not care about a broad CLI or daemon.
- You need a production backend email API, not a local user-facing workflow tool.
- You need a first-party MCP server right now. mxr has not shipped that yet.
Provider capability matrix
| Adapter | Sync | Send | Labels / folders | Mutations | Notes |
|---|---|---|---|---|---|
| Gmail | yes | yes | labels | yes | direct Gmail adapter |
| IMAP | yes | no | folders | yes | usually paired with SMTP |
| SMTP | no | yes | no | no | send-only adapter |
| Fake | yes | yes | fixture labels | yes | tests and local development |
Interface capability matrix
| Interface | Status | Best for | Notes |
|---|---|---|---|
| CLI | available | scripting, batch work, agents | broadest current surface |
| TUI | available | daily reading and triage | mailbox-focused interface |
| Daemon socket | available | custom clients | JSON over Unix socket |
| Agent skill | available | coding-agent workflows | documents CLI patterns |
| MCP server | not shipped | tool-native agent integration | planned, not current |