How to run cold email from Claude with MCP

The Model Context Protocol is an open standard from Anthropic that lets an AI assistant call external tools. Point Claude at an MCP server and it can do things rather than describe them.

Several cold email platforms now ship one. Most expose the reporting layer: read campaign stats, list leads, maybe update a sequence. That is useful and it is also the easy half. This walks through the harder half, which is doing the infrastructure setup through the assistant too.

Connect the server

claude mcp add --transport http raechly \
  https://reachly-mcp-server.capaxe.workers.dev/mcp \
  --header "Authorization: Bearer rk_your_key"

The bearer token is your organization API key and it is the tenant boundary. The MCP server forwards it to the API on every call, and the API resolves your organization from it.

No key yet? Add the server without the header. An anonymous connection sees exactly one tool, register_account, which creates the account and hands back a key. Save it, reconnect with the header, and the other 21 tools appear.

Ask for the whole setup at once

The interesting part of an agent interface is that you do not sequence the work yourself.

Set up mail.acme.com for outbound in eu-west-1, create two mailboxes, start warmup on both, then draft a three-step sequence for agency owners and leave it in draft.

What runs, in order:

1. create_domain — creates the SES identity, returns the DNS records
2. get_domain_dns — prints them again as a table you can copy
3. check_domain — polls SES until the identity verifies
4. create_mailbox ×2 — reply capture provisioned at creation
5. start_warmup ×2 — both move from pending to warming
6. create_warmup_pool_account — somewhere for warmup mail to land
7. create_campaign — three steps, left as draft

You publish DNS records in the middle. Everything else is the assistant.

Where it stalls, part one: DNS

The pause after create_domain is real and it is not the assistant’s fault. You get three DKIM CNAMEs, a MAIL FROM MX and SPF pair, and a DMARC record, and they have to be published at whoever hosts your zone.

The failure is almost always the same: two of the three DKIM records get added and the third is missed. SES needs all three. The identity sits unverified indefinitely, no error is raised anywhere, and nothing is failing because nothing is being attempted.

This is the one place where the assistant genuinely helps beyond saving keystrokes. Ask it directly:

check_domain on mail.acme.com and tell me exactly which record is missing

It polls SES, compares against what should be published, and names the gap. That loop takes seconds and replaces the twenty minutes normally spent staring at a DNS panel.

Where it stalls, part two: reply capture

Sending is gated on reply capture, so a mailbox with no verified inbound path will not send. This surprises people who have finished DNS and expect to be done.

Run reply-capture reconciliation and explain any mailbox that was skipped

reconcile_reply_capture walks every active mailbox and reports captured, skipped and errored. Skips are usually correct rather than broken: a domain whose MX points at Google Workspace is deliberately left alone, because enabling inbound routing on it would replace the MX carrying your actual company mail.

If that describes your sending domain, the fix is not configuration. It is a dedicated sending domain, which you should have anyway.

Then let it write the sequence

Once infrastructure is real, sequence writing is the part that benefits most from a model that can see your data.

Look at the leads I imported, then draft a three-step sequence for agency owners running outbound for clients. Problem-led first touch, case study on day 3, one-line breakup on day 7. Weekdays only, 9 to 5 Europe/London, 40 a day. Leave it in draft.

create_campaign takes the entire sequence in one call — every step with its subject, body and delay — plus the send window and the daily cap. Leaving it in draft matters. Campaigns only send when active, so drafting first lets you read the copy before anything leaves.

The send window is set here and enforced per lead in the campaign timezone, not per pipeline run. A lead in Berlin is not emailed at 3am because your server is in Virginia.

The debugging loop is the real win

This is what changes day to day. Something looks wrong, and instead of clicking between four screens:

Trigger the pipeline, then show me every failed send grouped by error and tell me what is causing them.

trigger_send runs the pipeline. list_activity returns the last hundred attempts with the verbatim error on each failure. The assistant groups them and tells you whether you are looking at rejected recipients, a throttle, or an SES-level refusal, which are three different problems that look identical in a status column.

Ask about volume and it will check list_mailboxes for sent_today against each daily limit, which usually explains “why is it sending so slowly” without anyone opening a dashboard.

What the assistant cannot do

Worth being clear about, because agent interfaces invite the assumption that everything is now possible.

Guardrails are server-side and apply identically to every caller. Send windows, per-mailbox and per-domain and per-campaign caps, the hard 30-per-day ceiling, address validation, the suppression list. Asking nicely does not raise a limit. trigger_send outside a campaign’s send window sends nothing for that campaign, and that is not a bug to work around.

It also cannot resurrect a suppressed lead. import_leads upserts by email and refuses to revive anyone who unsubscribed or bounced, regardless of how the import was initiated.

Is this actually better?

For campaign management alone, honestly, marginally. A good dashboard is fine for reading stats.

It is clearly better for two things. Setup, because DNS and identity verification are exactly the kind of multi-step, error-prone, easy-to-half-finish work where having something check your state and name the missing piece saves hours. And debugging, because grouping a hundred send errors by cause is tedious for a human and instant for a model with the log in front of it.

The gap between MCP servers in this category is mostly about whether they expose that first half. Reporting tools are common. Being able to say “why is nothing sending” and get an answer that spans DNS, verification, reply capture, warmup state and daily caps requires the setup tools to be there too.

---

Related reading: the full MCP tool reference, create_domain, and reconcile_reply_capture.