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.

Most cold email platforms now ship one. Many expose the campaign layer: read stats, list leads, update a sequence. That is useful and it is also the easy half. This walks through the harder half: getting a sending domain, finding the people and approving what goes out, all through the assistant.

Connect the server

The server is at https://mcp.raechly.com/mcp. In Claude, ChatGPT or Cursor, add it as a custom connector and sign in when asked. The sign-in page also creates the account if you don’t have one, so there is no separate sign-up step.

Claude Code and scripts use an API key instead. Create one in the dashboard under Settings › API keys, then:

claude mcp add --transport http raechly \
  https://mcp.raechly.com/mcp \
  --header "Authorization: Bearer rk_your_key"

Either way you are signed in to one organization, and every tool call acts on it alone. Give each script its own named key, so you can rotate or delete one without breaking the others.

Ask for the whole setup at once

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

Show me sending domain ideas for acme.com, order the first free one with senders anita, neha and sam, then draft a three-step campaign for heads of marketing at agencies in the UK.

What runs, in order:

1. sender_plan reports what your plan includes and what is already set up
2. domain_ideas lists lookalike .com names, each checked against the registry
3. order_senders places the order: the domain plus three sender names
4. create_campaign writes three steps and leaves them as a draft
5. set_campaign_icp turns “heads of marketing at agencies in the UK” into filters and returns a count and five anonymous examples, before anything is spent

The assistant stops there and shows you the audience. Nobody is found until you say yes; then confirm_campaign_icp finds them, at 15 credits a person, and adds them to the campaign.

Raechly buys the domain, publishes its DNS records, turns on reply capture and starts warming the senders. None of that needs you, and none of it touches the domain your company email runs on.

Where it waits: warmup

The pause is warmup, and it is deliberate. A new sender starts at a few emails a day and climbs over several weeks. Ask for the dates rather than guessing:

When will my senders reach full volume?

list_mailboxes returns each sender with ready_on, the day it reaches its full daily limit.

You don’t have to wait to launch. Approve the campaign with approve_campaign and turn it on; it shows as scheduled and starts by itself once a sender can send, slowly at first. If you’d rather send this week, list_ready_domains shows domains Raechly has already warmed for about three weeks. One costs $49 and sends the day you buy it.

If you bring your own domain

On the Business plan you can also send from domains and inboxes you already own, and then the old stalls come back.

create_domain returns three DKIM CNAMEs, a MAIL FROM MX and SPF pair, and a DMARC record to publish at whoever hosts your zone. The usual failure is that two of the three DKIM records get added and the third is missed; the identity then sits unverified with no error anywhere. Ask the assistant to run check_domain and name the missing record.

Sending is also gated on reply capture. reconcile_reply_capture reports which senders are captured and which were skipped. A domain whose MX points at Google Workspace is deliberately left alone, because routing its inbound mail would replace the MX carrying your company email. The fix there is a separate sending domain, which is what the plans include anyway.

Then let it write the sequence

With senders on the way, sequence writing is the part that benefits most from a model that can see your data.

Look at the people in the campaign, then write 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.

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. Every campaign starts as a draft, and nothing sends until you approve it. review_campaign_emails shows the real emails each person will get, filled in and signed by their sender. Read a few, ask for changes, and only then say yes, so the assistant calls approve_campaign.

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:

Show me every failed send from the last run, grouped by error, and tell me what is causing them.

Sending runs by itself every hour. 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, caps per sender, per domain and per campaign, address checks and the suppression list. Asking nicely does not raise a limit, and a campaign outside its send window sends nothing, which is not a bug to work around.

Approval stays with you. The assistant is told to call confirm_campaign_icp and approve_campaign only after you have seen the audience or the emails and said yes, and most clients ask before running a tool that writes.

It also cannot resurrect a suppressed lead. import_contacts 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 ordering senders, finding the people and writing the sequence is one request rather than an afternoon of screens, and on Business the DNS work is exactly the kind of easy-to-half-finish job 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, order_senders, set_campaign_icp and approve_campaign.