MCP Spotlight: Resend MCP Server — The Email Bridge With 10 Tool Groups, Send/Receive Symmetry, and the Transactional-Default Reference for Agents

Server: @resend/mcp by Resend License: MIT · Tools: ~25 across 10 tool groups (emails, contacts, broadcasts, domains, webhooks, segments, topics, contact properties, API keys, received emails) Coverage: The Resend email platform — transactional email, marketing email, contact management, broadcast campaigns, domain verification, webhooks, segments, topics (resend's unsubscribe/preference primitive), inbound email receiving Transport: stdio (NPX) or Hosted (mcp.resend.dev) · Auth: Resend API Key (per-environment, scoped) GitHub: github.com/resend/resend-mcp Docs: resend.com/docs/mcp-server · resend.com/mcp MCP Tracker: glama.ai/mcp/servers/resend

Every agent that handles notifications eventually needs email. The naive "give the agent raw SMTP credentials" approach violates modern security best practices and grants access to send from any address. The "wrap SMTP as MCP" approach duplicates the work every agent team would otherwise repeat. The "use a generic email API" approach leaks deliverability, scale, and analytics quality.

The official Resend MCP Server by Resend is the bridge that resolves this. ~25 tools across 10 tool groups covering the full Resend email platform — send and receive, transactional and marketing, contacts and broadcasts, all from a clean MCP surface. MIT-licensed, official Resend-maintained, available as both a self-hosted NPX package and a hosted MCP endpoint (mcp.resend.dev).

This is the transactional + marketing email default for AI agents in 2026. Modern protocol (HTTPS + JSON, not SMTP), Send/Receive symmetry, Contact management, Broadcast campaigns, and a tool surface that mirrors the email-domain mental model.

The Architecture: 10 Tool Groups

The Resend MCP Server organizes ~25 tools into 10 conceptual groups, mirroring how email platforms actually work:

Group	Tools	Purpose
Emails	send_email, send_batch_emails	Transactional + batch send
Received Emails	list_received_emails, get_received_email	Inbound email reading
Contacts	create_contact, list_contacts, get_contact, update_contact, delete_contact, subscribe_contact	Contact lifecycle
Broadcasts	create_broadcast, list_broadcasts, get_broadcast, update_broadcast, send_broadcast, delete_broadcast	Marketing campaigns
Domains	create_domain, list_domains, get_domain, verify_domain, delete_domain, update_domain	Sending identity
Webhooks	create_webhook, list_webhooks, get_webhook, delete_webhook, update_webhook	Event subscriptions
Segments	create_segment, list_segments, delete_segment	Contact segmentation
Topics	create_topic, list_topics, update_topic, delete_topic	Unsubscribe / preference management (required for EU compliance)
Contact Properties	create_contact_property, list_contact_properties	Custom contact fields
API Keys	create_api_key, list_api_keys, delete_api_key	Credential management

The 10-tool-group structure is the design lesson every "platform-as-MCP" server should copy: organize by domain concept, not by API endpoint. The agent thinks in terms of "send an email," "manage contacts," "verify a domain" — Resend's tool groups match.

The Killer Combination: Send + Receive

Resend is one of the few email platforms with first-class inbound (receive) support alongside outbound (send). The MCP server exposes both symmetrically:

Send

send_email(
  from="Acme <hello@acme.com>",
  to=["kevin@centerbit.co"],
  subject="Your trial expires in 7 days",
  html="<h1>Your trial expires in 7 days</h1><p>Click here to extend...</p>",
  text="Your trial expires in 7 days. Click here to extend: https://...",
  reply_to="support@acme.com",
  tags=[
    {"name": "category", "value": "trial-expiry"},
    {"name": "campaign_id", "value": "q3-lifecycle"}
  ]
)
  → Returns:
    {
      "id": "email_abc123",
      "from": "Acme <hello@acme.com>",
      "to": ["kevin@centerbit.co"],
      "created_at": "2026-07-18T14:32:00Z"
    }

Receive (inbound)

list_received_emails(
  limit=20,
  query="from:support@acme.com"
)
  → Returns:
    [
      {
        "id": "received_xyz789",
        "from": "Alice <alice@customer.com>",
        "to": ["hello@acme.com"],
        "subject": "Question about my subscription",
        "received_at": "2026-07-18T14:28:00Z",
        "message_id": "<abc@customer.com>"
      },
      ...
    ]

get_received_email(id="received_xyz789")
  → Returns full email content (HTML + text + headers + attachments)

For agents that participate in email triage workflows — "read incoming support emails, route to the right team, draft replies" — the Send/Receive symmetry is essential. The agent reads inbound, processes via reasoning, drafts and sends outbound.

The Batch Send Pattern

For lifecycle emails (welcome series, trial expiries, account reminders), batch send is the right primitive:

send_batch_emails(
  emails=[
    {
      "from": "Acme <hello@acme.com>",
      "to": ["user1@example.com"],
      "subject": "Your trial expires in 7 days",
      "html": "<rendered template for user1>",
      "tags": [{"name": "user_id", "value": "user_1"}]
    },
    {
      "from": "Acme <hello@acme.com>",
      "to": ["user2@example.com"],
      "subject": "Your trial expires in 7 days",
      "html": "<rendered template for user2>",
      "tags": [{"name": "user_id", "value": "user_2"}]
    },
    // ... up to 100 emails in one call
  ]
)
  → Returns array of {id, status} per email

The agent renders a template per user, batches the sends, gets back the per-email delivery IDs. 100x more efficient than 100 individual calls.

For high-volume sends, Resend also supports broadcasts (which use the broadcast campaigns system with audience segmentation), typically for marketing emails rather than 1:1 transactional.

The Broadcasts Pattern

For marketing campaigns with proper unsubscribe handling:

1. create_segment(
     name="Trial users",
     filter={"tier": {"equals": "trial"}}
   )
   → Returns segment ID

2. create_broadcast(
     name="Q3 Newsletter",
     segment_id="seg_abc",
     from="Acme <newsletter@acme.com>",
     subject="What's new in Q3",
     html="<full HTML template>",
     topics=["product-news", "company-updates"]  // preference topics
   )
   → Returns broadcast

3. // Test the broadcast by sending to internal emails first
   update_broadcast(id="bc_xyz", test_only=true)

4. // After review, schedule or send immediately
   send_broadcast(id="bc_xyz", scheduled_at="2026-07-20T14:00:00Z")
   → Returns confirmation

Broadcasts integrate with Topics — Resend's compliance-friendly primitive for managing per-topic unsubscribe preferences. For EU/GDPR compliance, every broadcast must respect the user's topic preferences.

The Domains Verification Flow

Email deliverability depends on verified sending domains. The MCP server exposes the full verification flow:

create_domain(name="acme.com", region="us-east-1")
  → Returns:
    {
      "id": "domain_xyz",
      "name": "acme.com",
      "status": "pending",
      "records": [
        {"type": "MX", "value": "feedback-smtp.us-east-1.amazonses.com", "priority": 10},
        {"type": "TXT", "name": "resend._domainkey", "value": "..."},
        {"type": "TXT", "name": "_dmarc", "value": "v=DMARC1; p=none; ..."}
      ]
    }

The agent prompts the user: "Add these DNS records to your domain at your DNS provider, then call verify_domain(id) once done."

verify_domain(id="domain_xyz")
  → Returns: {"status": "verified"}  // or "pending" with details on what's still missing

The agent polls until the status flips to verified. The user does the DNS configuration; the agent orchestrates the verification.

The Webhooks for Real-Time Events

For agents that react to email events:

create_webhook(
  url="https://fac.io/api/email-webhook",
  events=[
    "email.sent",       // queued for delivery
    "email.delivered",  // accepted by recipient server
    "email.bounced",    // hard bounce
    "email.complained", // marked as spam
    "email.opened",     // tracking pixel loaded
    "email.clicked"     // link clicked
  ],
  signing_secret="whsec_..."
)
  → Returns webhook configuration

The agent receives events at the Facio webhook endpoint, processes them via HITL gating, and updates the customer's record (e.g., mark as engaged, mark as bounced, suppress future sends).

The signing_secret parameter is critical — Resend signs every webhook payload, Facio verifies the signature before processing. Webhook spoofing is impossible.

The Topics (GDPR Compliance) Primitive

For EU DSGVO/GDPR and US CAN-SPAM compliance, every email must respect the recipient's preference topics. The Topics primitive is Resend's solution:

create_topic(
  name="product-news",
  description="Product updates, feature launches, and tips"
)
  → Returns: {id: "topic_a", name: "product-news", default_subscription: false}

When creating a broadcast, the user can specify topics=["product-news"] — meaning the broadcast only goes to users subscribed to that topic. Users control what they receive; the agent respects that.

For unsubscribe handling, the agent can mark a contact as unsubscribed from a topic:

subscribe_contact(
  contact_id="contact_xyz",
  topic_id="topic_a",
  subscribed=false
)
  → Marks unsubscribe preference

Or process an unsubscribe webhook:

// Webhook fires: "contact_xyz unsubscribed from topic_a"
// Agent updates the contact record
update_contact(id="contact_xyz", unsubscribed_topics=["topic_a"])

For multi-jurisdiction compliance (EU, US, UK, Canada), topics are the standard primitive. The agent doesn't try to implement unsubscribe logic from scratch; it relies on Resend's compliance-grade topic system.

Facio Integration

{
  "mcpServers": {
    "resend": {
      "command": "npx",
      "args": ["-y", "@resend/mcp"],
      "env": {
        "RESEND_API_KEY": "${credentials.RESEND_API_KEY}"
      }
    }
  }
}

Or use the hosted MCP server at mcp.resend.dev — no install, just connect:

{
  "mcpServers": {
    "resend": {
      "url": "https://mcp.resend.dev/mcp",
      "headers": {
        "Authorization": "Bearer ${credentials.RESEND_API_KEY}"
      }
    }
  }
}

The hosted option is the lowest-friction setup — OAuth-like onboarding, automatic updates, regional hosting for EU compliance.

Facio's audit trail captures every Resend MCP call with the tool, the email content (HTML + text sanitized), the recipient, the tags, and the delivery ID. For GDPR-compliant email handling, this is the audit artifact: "Agent at 14:32 UTC sent email to kevin@centerbit.co (id email_abc), subject 'Trial expiry reminder', tags trial-expiry, q3-lifecycle."

For HITL workflows, the email-send surface is the most sensitive — emails go to real people with real consequences:

Tool	Severity	Suggested Gate
list_*, get_*	Read	None — autonomous
send_email (1:1 to known recipient)	Write, contextual	Soft confirm (review the draft)
send_email (1:1 to new recipient)	Write, contextual	Hard confirm (cold outreach)
send_email (mass/bulk)	Write, contextual	Hard confirm + reason + recipient-count review
send_batch_emails (>10 recipients)	Write, contextual	Hard confirm + reason + recipient-list review
send_broadcast (marketing)	Write, contextual	Hard confirm (campaign-level)
create_webhook, update_webhook	Write, contextual	Soft confirm
delete_webhook	Write, contextual	Soft confirm
create_domain, verify_domain	Write, contextual	Soft confirm
delete_domain	Write, destructive	Hard confirm (impacts deliverability)
subscribe_contact (unsubscribe)	Write, contextual	Soft confirm (or autonomous if from webhook)
delete_contact	Write, destructive	Hard confirm (GDPR right-to-erasure implications)

The send_email and send_batch_emails tools deserve special attention — emails are immediately visible to the recipient, are not revocable, and have direct compliance implications (especially in EU under GDPR). Facio should require:

• Soft confirm for known recipients (existing customers)
• Hard confirm + reason for new recipients (cold outreach)
• Hard confirm + recipient list review for any batch send
• Hard confirm for marketing broadcasts (which by law must offer unsubscribe via Topics)

The delete_contact tool is particularly sensitive — under GDPR's right-to-erasure, contact deletion may be legally required. Facio should require hard confirmation with a stated reason (data subject request, retention policy expiry, account closure).

For multi-environment setups (dev / staging / prod), the pattern is one API key per environment. Each environment has its own Resend subdomain, its own audience, its own analytics. The agent switches context per environment.

For multi-tenant SaaS setups (one Resend sending identity per tenant), the pattern is one API key per tenant, scoped to that tenant's domains and audiences. The audit trail is per-tenant.

Quickstart

# 1. Get a Resend API key
#    https://resend.com/api-keys

# 2. Configure your MCP client (hosted, lowest friction)
{
  "mcpServers": {
    "resend": {
      "url": "https://mcp.resend.dev/mcp",
      "headers": {
        "Authorization": "Bearer re_..."
      }
    }
  }
}

# Or self-host via NPX
npm install -g @resend/mcp
{
  "mcpServers": {
    "resend": {
      "command": "npx",
      "args": ["-y", "@resend/mcp"],
      "env": {
        "RESEND_API_KEY": "re_..."
      }
    }
  }
}

# 3. First prompts
# "Send a welcome email to kevin@centerbit.co"
# "Show me our open rates this week"
# "Draft the Q3 newsletter and schedule it for Monday"
# "Process the unread emails in our support inbox and route them to teams"

Use Cases

Transactional email sending: "Send a welcome email when a new customer signs up." Customer creation → email send → tracking.

Trial expiry reminders: "Find customers whose trial ends in 7 days, send reminder emails." CRM query → batch template → email send.

Support email triage: "Read the support inbox, classify each email, route to the right team." Receive → classify → tag or forward.

Welcome series: "Set up a 5-email welcome series for new signups, with delays between each." Broadcast sequence with scheduling.

Re-engagement campaigns: "Find users who haven't logged in for 30 days, send a re-engagement email." Inactivity query → targeted email.

Newsletter automation: "Draft the monthly newsletter, review for tone, schedule for the first Monday." Content drafting → review → broadcast scheduling.

Domain setup: "Set up sending from hello@acme.com — verify the DNS, troubleshoot any issues." DNS records → verification → status check.

Webhook event handling: "When a customer emails support, route to Slack, log to Linear." Receive webhook → process → cross-tool action.

Bounce management: "Process the bounce notifications, suppress hard bounces from future sends." Webhook → contact update → audit.

Spam complaint handling: "Process the spam complaints, auto-unsubscribe the contact, flag for review." Webhook → unsubscribe → notification.

A/B testing: "Send version A to 20%, version B to 20%, declare winner by open rate after 48 hours." Broadcast split → analytics.

Personalization: "Personalize the welcome email with each user's name and signup date." Template rendering with contact properties.

Email templates versioning: "Create the new welcome template, A/B test against the current version." Template CRUD → broadcast split.

Compliance auditing: "Generate the report of all emails sent in Q3, including per-recipient unsubscribe status." Audit export.

Multi-region sending: "Set up sending infrastructure in EU region for our European customers." Region-specific API keys.

Customer preference management: "Process the user's preference update, apply to all topics." Subscribe/unsubscribe per topic.

DKIM/SPF/DMARC verification: "Audit our domain setup for deliverability best practices." Domain verification → status check.

Email deliverability monitoring: "Track bounce rate, complaint rate, open rate. Alert if any crosses threshold." Webhook analytics → anomaly detection.

Lifecycle campaigns: "Build the trial-to-paid conversion sequence: day 1 welcome, day 3 setup help, day 7 feature highlight, day 14 trial end, day 15 paid conversion." Multi-email sequence with timing.

Inbound to ticket conversion: "When a customer emails support, create a Linear ticket with the email content." Receive → ticket creation with email body.

The Domain-Grouped Tool Surface Pattern

The Resend MCP server's defining design choice — organize tools by domain group, not by API endpoint — is the design lesson every "broad-platform-as-MCP" server should copy.

Why domain-grouped wins:

• Mental model match — the agent thinks in "send email / manage contacts," not "POST /v1/emails with X envelope"
• Tool discoverability — 10 groups is easier to navigate than 50 standalone tools
• Semantic RBAC — "I can send emails but not manage domains" maps to per-group permissions
• Documentation clarity — each group has a clear purpose, easy to teach the agent
• Composability — domain groups compose into workflows (verify domain → set up webhook → send first email → monitor deliverability)

For any broad-platform MCP server (HubSpot, Zendesk, Salesforce, etc.), domain-grouped tool surface is the right pattern. The alternative — flat list of 50+ tools — bloats the context window and loses semantic structure.

The Topics (Compliance) Pattern

The Resend MCP server's second defining innovation — Topics as a first-class primitive for preference management — is the design lesson every "communication-as-MCP" server should learn.

Why Topics win:

• GDPR Article 7 compliance — consent per topic, per recipient, easily auditable
• CAN-SPAM compliance — unsubscribe per topic, not all-or-nothing
• User agency — recipients control what they receive, the agent respects the choice
• Audit-ready — every send has the topic context, every unsubscribe is logged
• Right-to-erasure compatible — delete contact, the topics dissolve

For any communication platform (email, SMS, push notifications, Slack messages), per-topic preference management is the EU-grade compliance primitive. The agent doesn't try to implement consent logic from scratch; it relies on the platform's compliance-grade topic system.

Bottom Line

The Resend MCP Server is the transactional + marketing email default for AI agents in 2026. ~25 tools across 10 domain groups, send/receive symmetry, Topics compliance primitive, webhook-driven event handling, MIT-licensed, official Resend-maintained. Available as both self-hosted NPX and hosted mcp.resend.dev.

For any agent that participates in customer communication — transactional email, lifecycle campaigns, support triage, newsletter automation, re-engagement sequences, inbound routing, bounce management — this is the bridge. The agent sends via Topics-scoped consent, processes inbound emails, manages contacts, sets up domains, monitors deliverability. All with full GDPR/CAN-SPAM compliance.

For the broader MCP ecosystem, the Resend pattern is the design lesson every "broad-platform-as-MCP" server should copy. Domain-grouped tools + symmetric send/receive + Topics-compliant preference management. When the email platform is right, the agent's communication is right.

npx -y @resend/mcp with RESEND_API_KEY=re_... (or connect to hosted mcp.resend.dev) and your agent has email.

---

MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for design clarity, ecosystem impact, and integration fit with Facio's HITL-first agent runtime.