MCP server

FounderMail runs a hosted Model Context Protocol server at https://mcp.foundermail.mx. Connect an assistant to it and it can list your mailboxes, read mail, write drafts and manage templates, using the same API key as the REST API. The server uses the streamable HTTP transport. API keys, and with them the MCP server, are on every plan, the Free one included.

It can draft, and it can send. draft_reply leaves the message in the mailbox's Drafts folder, where it shows in the dashboard and in any IMAP client and a person sends it; send_email sends it there and then. An assistant that can send from your domain is a real risk, so give it a key scoped to mail:draft alone if you want the loop to stop one step short — and note that most domains may only reply to people who have written in, which limits what a sending assistant can do to strangers.

Connecting

Create a key under Settings → API keys, then add the server to your client with the key as a bearer token.

Claude Code

claude mcp add --transport http foundermail https://mcp.foundermail.mx \
  --header "Authorization: Bearer YOUR_API_KEY"

Any client that takes a JSON configuration (Cursor, VS Code, Windsurf and others)

{
  "mcpServers": {
    "foundermail": {
      "url": "https://mcp.foundermail.mx",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Clients that only speak the local stdio transport can reach the server through a bridge such as mcp-remote, passing the same header.

Tools

Tool	Parameters
`list_inboxes`	—	The mailboxes the key can reach, with their addresses.
`get_inbox`	`inbox_key`	One mailbox: address, message count, size, enabled.
`list_emails`	`inbox_key`, `skip`, `take`, `since`	Messages in a mailbox, newest first. `take` defaults to 10, capped at 25. `since` (ISO 8601) lists only what arrived at or after that time.
`get_email`	`inbox_key`, `message_id`	One full message, body included.
`get_last_email`	`inbox_key`, optional `template`	The most recent message, optionally parsed with a template.
`draft_reply`	`inbox_key`, `to`, `subject`, `body`, `is_html`, optional `draft_id`	Writes a draft from the mailbox. With `draft_id` it overwrites an existing draft instead of creating a second one. Never sends.
`list_drafts`	`inbox_key`	Drafts already written, so the assistant does not duplicate one.
`send_email`	`inbox_key`, `to`, `subject`, `body`, `is_html`, `in_reply_to_message_id`, optional `cc`, `bcc`	Sends now, from the mailbox's own address. Needs a key with `mail:send`. Counts against the plan's allowance.
`list_templates`, `create_template`, `test_template`, `delete_template`	see Templates	Extraction templates with `{{var}}` placeholders.

The inbox key is the local part of the address (support for support@yourdomain.com); use the full address when the same key exists on two of your domains.

What it is good at

Catching up. "What came in overnight that needs an answer, and from whom?" across every mailbox at once.
Drafting the routine replies. Invoice queries, DNS questions, "does my plan include X": read the thread, write the reply, leave it in Drafts for a person to check and send.
Turning repeated mail into data. Write a template for a supplier's order confirmations once, then read every new one as fields.

Limits and safety

The server has the permissions of the API key and nothing more. Delete the key in Settings to revoke an assistant's access at once.
Requests count toward the plan's request rate, the same as REST calls.
The server cannot change DNS or domains, cannot delete messages, and cannot read another workspace. It sends only from your own mailboxes, under the same rules as the dashboard.
Contact records are not writable from the MCP server; use the REST API for that.