MailFathom: an MCP search service that syncs IMAP mailboxes into your own PostgreSQL

Who it's for

MailFathom synchronizes multiple IMAP mailboxes into a PostgreSQL database you run yourself, indexes that copy, and hands it to AI as MCP (Model Context Protocol) tools. It fits:

• people who want AI to search their mail and answer mail-related questions instead of digging through webmail again and again;
• individuals or small teams that already self-host and are willing to run the database and the service process themselves;
• users who care about data boundaries and want the mail copy and its index to live only on their own machines;
• anyone holding several IMAP mailboxes who wants AI to search them all in one place: multiple accounts sync into the same database.

What it takes, and what it is not:

• It is not a hosted service: PostgreSQL and MailFathom itself are yours to run and maintain, so it does not suit people who refuse to manage a server;
• The evidence only covers IMAP mailbox synchronization; whether other mail protocols, calendars, or deep attachment parsing are supported is not stated and remains unconfirmed;
• Write operations — marking, drafting, sending — are all off by default, and each account and each credential must be granted separately before anything turns on. If you expect an install that lets AI touch your mailbox right away, you must first accept this per-account authorization flow.

A first try in three minutes

There is exactly one recommended path: clone the official repository and run the quick-start script.

git clone https://github.com/fathomise/MailFathom.git
cd MailFathom
scripts/quick-start-compose.sh

Preconditions: a machine you control, and acceptance that the mail copy will live in the PostgreSQL you run. The ports and environment variables the script needs are not stated in the evidence, so read the script before running it. Afterwards, connect the service to your AI client as MCP; the exact client configuration is not given in the evidence, so follow the repository's instructions.

For a first call, try list_accounts: it is a reading tool and involves none of the write actions — marking, drafting, sending. The success signal is AI returning the list of synced accounts. To go one step further, call search_emails with keywords; results are ranked lexically, and once you configure an embedding model the ranking also weighs semantic similarity.

Everything read comes from the copy synced into the database; how often a sync round runs and how far the copy lags the real inbox are not stated and remain unconfirmed.

Note: read-only is not zero risk — the reading tools can see every message synced into the database; which mailboxes enter the copy and how the sync scope is controlled are not stated and remain unconfirmed.

Use cases

Case 1: recover an old message by keyword. Scenario: you remember that some email mentioned a word, and you would rather not page through the inbox. Approach: have AI call search_emails with the keyword. What to expect: a list of matching messages ranked lexically (plus semantic similarity once an embedding model is configured); when you need full text, use get_email_content, which serves up to ten messages in full per call.

Case 2: ask a question across many messages. Scenario: questions like what was said about this matter before and after, which require piecing several emails together. Approach: call ask_mail and ask one natural-language question. What to expect: an answer grounded in your synced mail, citing one by one every message it drew on; how far the answer reaches depends on the mail actually synced into the database.

Both cases use reading only. To mark, draft, or send, you must first enable the matching write permission per account and per credential — this is the official design, not a malfunction.

Boundaries

• Read versus write: the reading tools (list_accounts, list_emails, search_emails, get_email_content, ask_mail) and the write operations (marking, drafting, sending) are strictly separated; write capabilities are off by default and must be granted per account and per credential before they turn on. Whether a write operation acts on the real mailbox or on the local synced copy is not stated and remains unconfirmed; whether an undo path exists is likewise unconfirmed.
• Credentials and data: what gets synced is your IMAP mailbox, and both the copy and its index live in your own PostgreSQL; how IMAP credentials are submitted, how they are stored, and whether they are encrypted are not stated and remain unconfirmed.
• Retrieval and answer quality: search_emails ranks lexically by default, and semantic similarity only takes effect after you configure an embedding model; ask_mail's answers and citations stand on synced mail alone, so anything not synced cannot be asked about.
• Side effects and checkpoints: enabling each write permission is a checkpoint you should think through — enable only the one you truly need; the concrete effect of a write operation is not stated in the evidence, so for a first try leave write permissions off and stick to the reading tools.
• Tool scope: officially, twenty-one tools are the whole surface; no evidence backs any capability beyond them, so do not assume “it probably works too”.
• Key open questions: where write operations take effect, how IMAP credentials are stored, installation paths other than the quick-start script, specific configuration options and performance limits, and sync frequency are all uncovered by the evidence; the license type is AGPL-3.0-only (as marked in the source title) and the full text is not included — refer to the official repository.