An email MCP server that gives the agent the mailbox too

Two kinds of email MCP server: the ones that send, and the ones that want your mailbox

Search this term and you get a category that looks unified and is not. Work through what currently ranks and every option falls into one of two groups, and both groups quietly assume you have solved the same problem before you arrive.

Group one: vendor sending servers. The best-known roundup on this query tested seven of them — Mailtrap, Mailgun, Brevo, Postmark, SendGrid and company. They wrap a transactional sending API in MCP tools, so your agent can compose and send. To use one you need an account with that vendor, a verified sending domain, and an API key. What none of them gives you is somewhere for a reply to land.

Group two: bring-your-own-mailbox servers. Two personal GitHub repositories rank on the first page by wrapping IMAP and SMTP in MCP tools; Google's own documentation covers a Gmail MCP server that operates the mailbox you already log into. These do receive. The cost is what you hand over: a host, a port, a username and a password in a config file, or an OAuth consent that gives an automated process access to a human being's personal mail — the account with your bank statements and your password resets in it.

So the question the category never answers is where the mailbox comes from. Group one says buy a sending account. Group two says use your own. Both answers are wrong for the same job, which is giving the agent an address of its own — one that can receive a verification code, take a reply from a customer, and be shut off in one command when the experiment ends, without touching anything a person depends on.

Clize answers by issuing the mailbox. One command creates the address; the MCP server then operates it. There is no IMAP host to look up, no app password to generate, no consent screen, and no shared vendor sender to migrate off later.

Install it in Claude Code, Codex or OpenClaw

The server ships in the same npm package as the CLI, as a second binary called clize-mcp. Install the package, log in, and let clize install register it in whichever host you use:

$ npm i -g @clize/clize
$ clize login
$ clize install --claude --mcp     # or --codex --mcp, --openclaw --mcp

Note the --mcp flag. Without it, clize install writes only the skill — a plain instruction file that teaches the agent to call the CLI — and registers no MCP server at all. That is the default on purpose: an MCP tool list occupies the context window in every session whether the agent uses it or not, while a skill costs nothing until the model reads it. Pick MCP when you want structured tool calls with typed arguments; pick the skill when you want the terminal.

If you would rather register it by hand, or you want the narrowed inbox tool set rather than everything, these are the exact commands per host:

# Claude Code / Codex — note the -- separator before the command
$ claude mcp add clize -- clize-mcp --profile inbox
$ codex  mcp add clize -- clize-mcp --profile inbox

# OpenClaw — different syntax: no separator, the stdio command goes in --command
$ openclaw mcp add clize --command clize-mcp

Pi reads the same open ~/.agents/skills directory as Codex and OpenClaw, so clize install --pi delivers the skill. Its MCP registration syntax is not something we have measured, so the installer does not guess at it — register clize-mcp by hand from Pi's own documentation if you want the tool surface there.

The 13 tools in the inbox profile

Started with --profile inbox, the server reports itself to the host as clize-inbox and registers exactly these thirteen tools. Nothing else appears in tools/list, so nothing else costs you context:

The last three are the account surface every profile shares. They are there because an agent that cannot see the balance cannot explain why an action failed, and an agent that cannot produce a top-up link has to hand the problem back with no next step.

Leave --profile off and you get the full server — 32 tools covering domains, DNS, deploys, payments, media and SEO alongside the mail ones. Pass a value that is not a profile name, or pass the flag with nothing after it, and the server refuses to start and says so. It never silently falls back to the full set, because silently registering 32 tools when someone asked for 13 is the kind of surprise you only find by reading the context window later.

A mailbox with no IMAP credentials and no OAuth

Here is the whole setup for an agent that can receive mail, with nothing omitted:

$ clize claim studio --email
# → support@studio.clize.app, receiving

That is the part the other servers cannot do, so it is worth being precise about what happens. The handle is yours on a first-come basis, a placeholder site goes up immediately, and --email opens inbound on the address. Inbound is off unless you ask for it, because opening a mailbox consumes DNS records on a zone shared by every free handle, and that zone's record limit is the real ceiling on how many exist. You can add it later with clize email setup instead.

For anything customer-facing, use a domain you own: clize email setup yourdomain.com turns on Cloudflare Email Routing, writes the MX and SPF records, and creates mail.yourdomain.com as the sending subdomain, submitted for verification. To be exact about the boundary — DKIM and DMARC records are not written for you.

What is absent from all of that: no IMAP host or port, no app password in a config file, no OAuth consent, no vendor account created before you start, and no personal mailbox exposed to an automated process. Mail is stored on the platform, so clize_email_search is a real search over history rather than a fetch against a live IMAP connection that might be rate-limited or asleep.

The job everyone tries first: reading a verification code

The first useful thing an agent does with an inbox is finish a signup. It fills the form with its own address, and then it has to wait for a message that has not arrived yet — the point where a plain "read the inbox" tool turns into a polling loop the model has to invent.

clize_email_inbox has the wait built in. Call it with waitFor and it blocks until a message whose subject, sender or body contains that text arrives, up to timeoutSec seconds — 120 by default:

{ "domain": "studio.clize.app", "waitFor": "verification code", "timeoutSec": 180 }

The same thing from the terminal is clize email inbox --wait-for "verification code". One call, one result, no loop for the model to get wrong and no fixed sleep that is either too short or wastes three minutes.

Two details that make the difference in practice. Verification mail is classified otp, which is one of the two classes returned by default, so it is never filtered away as automated noise. And every read prints an untrusted marker to stderr before the output, which matters most here: a signup confirmation is exactly the kind of message an attacker would imitate. The verification walkthrough covers the full sequence.

A profile is a context budget, not a permission boundary

It is tempting to read --profile inbox as a sandbox. It is not, and confusing the two is how people end up trusting the wrong thing.

The profile decides which tools appear in tools/list. That is a context-window decision, and a good one: thirteen tool descriptions instead of thirty-two is real budget back in every session. It is not an authorisation decision. The credentials behind the server are the same either way.

The gates are elsewhere, in the commands themselves, which is why they survive the switch. clize_email_send without confirm returns a draft inside MCP exactly as clize email send does in a terminal. Anything that costs money returns a quote first. Inbound is labelled untrusted on every read. None of that is provided by the profile, and none of it can be turned off by choosing a different one.

When you do need a real permission boundary — a key that genuinely cannot do a thing — issue a scoped key instead: clize email key create --scope read,send --address support@yourdomain.com produces a credential restricted to named mailboxes, revocable on the spot. The comparison page works through where each of those belongs.

Where to find it

The server is published in the official MCP registry as ai.clize/clize, pointing at the @clize/clize npm package with clize-mcp as its stdio entry point. A host that discovers servers from the registry finds it there; everyone else installs the package.

One package covers every product line. The tool surface is what varies, by --profile: inbox for mail, storefront for payments and fulfilment, sites for deploys, domains for registration and DNS. Tool names never change between profiles, so switching one does not make the agent relearn the command surface.

If the terminal suits you better than a tool list, the skill alone is enough and costs no context — the Agent Inbox overview shows that path. If you want mail to reach your own HTTP endpoint rather than the agent, the inbound webhook guide is the other half.

$ npm i -g @clize/clize && clize login
$ clize install --claude --mcp
$ clize claim studio --email