Send Email from AI Agents with MCP

Send email from AI agents with MCP

Disclosure: SendNeo is built by Yorker Media, the team behind this blog.

An AI agent can draft a receipt, add a subscriber, or prepare a newsletter. Sending the final message is a separate action because it affects real recipients. Model Context Protocol (MCP) gives an agent a structured way to call SendNeo, while the account, key, review mode, and broadcast confirmation keep the dangerous step visible.

The goal is not to let a prompt silently send mail. The goal is to make useful email actions inspectable, testable, and easy for a human to approve.

What the SendNeo MCP server exposes

SendNeo’s Streamable HTTP MCP server is at:

https://sendneo.yorkermedia.com/mcp

It provides send_email, get_email, list_domains, add_domain, verify_domain, list_audiences, add_contact, create_broadcast, test_broadcast, send_broadcast, and get_usage.

send_broadcast is marked destructive and asks the human first. Keep that behavior enabled. Reading usage or listing an audience is a different risk from delivering a campaign to thousands of people.

Claude Code setup

Create a test key first and keep it in an environment variable:

export SENDNEO_API_KEY='sn_test_your_key'
claude mcp add --transport http sendneo \
  https://sendneo.yorkermedia.com/mcp \
  --header "Authorization: Bearer $SENDNEO_API_KEY"

Give the agent a task such as “list the audiences and show the draft details.” Ask it to create or test a broadcast, then review the result. Do not put a live key in a repository, issue, transcript, or prompt.

Claude.ai, ChatGPT, Cursor, and Codex

In a connector or custom MCP configuration, add the URL and an HTTP header:

Authorization: Bearer <your SendNeo key>

Cursor accepts the same endpoint in its MCP settings. Codex can add it as a custom Streamable HTTP server. Use each client’s secure secret storage, and scope the key to the workspace or task that needs it. If the client cannot keep a header secret, use a test key or call a small application proxy that you control.

A safe agent sequence

A reliable sequence separates preparation from delivery:

1. Inspect. Ask the agent to list domains, audiences, and current usage.
2. Draft. Create a broadcast with a clear subject, audience, and content. Keep private data out of the prompt.
3. Preview. Run test_broadcast and inspect the rendered result, links, sender, and unsubscribe.
4. Confirm. Show the human the audience, recipient count, subject, schedule, and final body. Ask for approval.
5. Send. Call send_broadcast only after that approval. Use a schedule when the team needs a final review window.
6. Monitor. Read delivery, bounce, complaint, unsubscribe, and reply signals through the product and webhooks.

For a transactional message, the agent can call send_email, but the same review principle applies. A receipt can be generated from an order event, while a marketing offer needs explicit rules about audience and consent.

Test without real mail

Use an sn_test_ key during prompt development. delivered@test.sendneo.dev simulates delivery, bounced@test.sendneo.dev simulates a bounce, and complained@test.sendneo.dev simulates a complaint. Any other address returns a delivered result in test mode. Test sends are free and unlimited, with a maximum of 50 recipients per call.

A test key never sends real mail, so an agent can exercise error handling and webhook verification without creating an accidental campaign. Once the application is ready, a new account still begins in review; live mail to outside recipients opens after a quick human review, usually within one business day.

Keep the tool boundary small

An agent does not need every capability. A content editor may need list_audiences, create_broadcast, and test_broadcast, but not add_domain. A support workflow may need send_email and get_email, but not a campaign sender. Disable tools that the task does not require.

Use an idempotency key for retries on transactional requests. Ask the agent to include the intended recipient and message purpose in its confirmation summary. For a broadcast, show the exact audience and schedule rather than saying only “the newsletter is ready.”

MCP does not bypass SendNeo’s domain verification, account review, rate limit, suppression, or deliverability guardrails. The server still requires a bearer key. Rotate the key if it appears in a log, and keep webhook signing secrets separate from API keys.

Build a human-readable audit trail

Record who approved a send, which draft was tested, the audience ID, the message or broadcast ID, and the schedule. Store the event ID from webhooks so retries do not create duplicate actions. If an agent changes a contact, make the change visible in your application log.

A concise approval record can look like this:

Action: send_broadcast
Audience: product-updates
Subject: October release
Schedule: 2026-10-16 18:00 UTC
Test: passed with test key
Approved by: editor@example.com

The record turns a natural-language request into a decision someone can audit later.

Where MCP fits

MCP is useful for repetitive, structured tasks: checking usage before a launch, preparing a test issue, adding a confirmed contact, or looking up a delivery ID. It is not a replacement for consent, editorial review, or incident response. Keep the final send as a distinct, destructive step and let a human see the exact scope.

Read MCP setup, Test mode, and Newsletters for the product details. A careful tool boundary lets an agent save time without turning a mistaken prompt into an irreversible broadcast.

Design prompts around decisions

A useful instruction gives the agent constraints it can check: “Prepare a test broadcast for the Product Updates audience, show the subject and recipient count, and do not send.” A risky instruction leaves the audience implicit: “Send the launch email.” Ask for the agent’s proposed tool calls before a destructive operation when your client supports that view.

For transactional workflows, keep recipient selection in application data rather than letting a model infer addresses from prose. Pass the order ID and a known template, then let the agent look up the resulting message status. A model can help explain a failure without receiving the entire customer database.

Failure and recovery

An MCP request can time out even when the server accepted the call. Use an idempotency key for transactional sends and inspect the returned message ID before retrying. For a broadcast, read its state and approval record instead of issuing another send call. If a webhook arrives twice, deduplicate by event ID.

Keep a test key in CI and rotate a live key after a team member leaves or a log is exposed. Separate API keys from webhook signing secrets. A prompt should never be the place where a secret is copied for convenience.

A small operational policy

Teams can write a short policy beside the connector: test keys for drafts, live keys only in secure settings, no broadcast without a named approver, no audience import without a consent source, and an audit record for every send. The policy is short enough to read and concrete enough to enforce.

The result is a useful middle ground. An agent can inspect usage, prepare an issue, add a confirmed contact, and explain delivery events. A person remains responsible for the audience and the final broadcast. MCP supplies the structured boundary; your process supplies the judgment.

Start with read-only tools and add write tools only after the team understands the client’s confirmation behavior. A gradual rollout gives editors time to learn the summaries and gives engineers time to verify retries, webhooks, and secret rotation before an agent touches a live audience.

If you are choosing the underlying API first, Resend alternatives compares the main transactional paths.