Guide

Give your AI a send button

Connecting an MCP email server to Claude or ChatGPT — and what changes when a model can actually send.

Your model can already write a decent email. What it usually cannot do is send one. So the workflow ends the same way every time: the model produces HTML, you copy it, you paste it into some dashboard, you fix what the paste broke, you press send. The intelligence is in the chat and the plumbing is somewhere else.

MCP — the Model Context Protocol — closes that gap. It is a standard way to hand a model a set of tools it can call. Point it at an email platform and the model stops producing text for you to carry somewhere, and starts operating the platform directly.

Connect it

Charlie exposes an MCP server. In Claude, ChatGPT or Gemini, add a custom connector with this endpoint:

https://charlieai.co/mcp

Authenticate with OAuth or an API key. That's the whole setup — no SDK, no client code. Everything below happens in the chat.

What the model can then do

Once connected, the tools cover the full lifecycle rather than a token "send email" function:

• Set up sending — check a domain's authentication state, produce the exact DNS records, verify them once they propagate.
• Build the mail — browse 448 templates, adapt one to a brand, render a preview.
• Test safely — send to your own inbox before anything goes near a list.
• Send for real — a campaign to a segment, or one personalised message per recipient.
• Read back — deliverability state, what was sent, who unsubscribed.

A working session looks like ordinary conversation: "Check whether send.myapp.com is authenticated. If it isn't, give me the records. Then draft a welcome email in our tone, show me a preview, and test-send it to me." The model does each step by calling tools, and you approve what matters.

The part people get wrong

Giving a model a send button is genuinely risky, and the risk is not that it writes something embarrassing — you'll see that in the preview. The risk is the quiet, expensive kind: sending from a domain with no DKIM signature, mailing an address that hard-bounced last week, omitting the one-click unsubscribe header Gmail requires from bulk senders, or blasting an entire list from a brand-new domain with no warmup.

A human sender learns these rules over years of getting burned. A model has no such scar tissue, and it operates at 3am when nobody is watching.

So the platform has to hold the rules instead of the operator. In Charlie's case that means: no sending at all from an unauthenticated domain (no override flag exists), suppression enforced on every path including transactional, RFC 8058 one-click headers injected per recipient on marketing sends, and automatic warmup with new senders on probation IP pools. An agent cannot opt out of any of it, which is precisely the point — the guardrails are the feature, not the limitation.

When to use the API instead

MCP is for the model. Your application should still call the REST API directly: it's deterministic, testable and doesn't require a chat session to be open. Most teams end up using both — the API for the mail their app sends on its own, MCP for the parts a human plus a model decide together, like a campaign or a debugging session.

# what your app does, no model involved
curl -X POST https://charlieai.co/ext/v1/transactional \
  -H "Authorization: Bearer $CHARLIE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome",
       "html":"<p>Thanks for signing up.</p>"}'

Same pipe, same domain authentication, same suppression list. The difference is only who is driving.