Model Context Protocol

The email MCP server your agent can be trusted with

71 tools over streamable HTTP: send, build automations, own an inbox, and read back what happened. The interesting part is not the sending. It is what stops the sending when it should.

Endpoint https://sending.dev/api/mcp · streamable HTTP · API key or OAuth 2.1

Install it in your client

What holds when the agent is wrong

An autonomous agent sending real email is a thing worth being nervous about. These are the six mechanisms that make it survivable, and all six run on our servers, where a prompt cannot reach them.

Verified domain

An agent can only send from a domain whose SPF, DKIM and MAIL FROM we have checked. A domain it has not verified is not a domain it can send from.

Suppression

Hard bounces, complaints and unsubscribes are dropped before the send, and reported back so the agent knows what happened rather than assuming success.

Idempotency

Every send needs a key, minimum 8 characters, in the body. An agent that retries cannot mail the same person twice, which is the failure mode that costs the most trust.

Spend and volume caps

Per API key, per day. The ceiling is a number you set, not a promise the model makes.

Audit log

Every tool call is recorded with its arguments. When something goes out that you did not expect, you can find out what asked for it.

Scopes

Permissions come from the user-client binding, not from the token, and you change them without reconnecting the client.

The 71 tools

An agent that can only send is an agent that comes back to you for everything else. The rule we hold ourselves to: whatever writes must come with the tool that reads the id it needs, the tool that re-reads and fixes what it created, and visibility into the side effects.

Domini e usage

  • list_domains
  • verify_domain
  • set_domain_sender_name
  • get_usage
  • set_frequency_cap

CRM

  • list_contacts
  • upsert_contact
  • list_tags
  • create_tag
  • update_tag
  • delete_tag
  • tag_contacts
  • list_lists
  • create_list
  • update_list
  • delete_list
  • add_contacts_to_list
  • remove_contacts_from_list
  • list_segments
  • create_segment
  • estimate_segment
  • create_custom_field

Template

  • list_templates
  • get_template
  • create_template
  • update_template

Invio

  • send_email
  • send_message
  • list_campaigns
  • get_campaign
  • get_campaign_metrics
  • create_campaign
  • update_campaign
  • estimate_campaign
  • send_campaign

Allegati e immagini

  • upload_attachment
  • list_attachments
  • delete_attachment
  • upload_image
  • list_images

Automazioni

  • list_automations
  • get_automation
  • create_automation
  • update_automation
  • activate_automation
  • enroll_contacts
  • test_automation
  • get_automation_log
  • get_automation_stats

Agent Email

  • list_inboxes
  • create_inbox
  • list_threads
  • get_thread
  • send_from_inbox
  • reply_thread
  • get_agent_email_metrics

Webhooks e regole

  • list_webhooks
  • create_webhook
  • delete_webhook
  • list_email_rules
  • create_email_rule
  • delete_email_rule

Attribuzione

  • get_utm_summary
  • list_utm_touches
  • list_utm_conversions
  • get_contact_conversions
  • get_contact_journey
  • get_conversion_stats

Import

  • connect_activecampaign
  • start_activecampaign_import
  • get_import_status

Questions

What is an email MCP server?

An MCP server exposes a product as tools an AI agent can call directly, instead of an API the agent has to be taught. For email that means sending, but also verifying a domain, building an automation, reading an inbox and asking why a message never left. Sending exposes 71 of them over streamable HTTP at https://sending.dev/api/mcp.

What stops an agent from sending something it shouldn't?

Five things, all enforced server-side: sending is only allowed from a verified domain, suppressed addresses are dropped, every send needs an idempotency key, each key carries per-day volume and spend caps, and every tool call is written to an audit log. None of it lives in the prompt, so an agent cannot argue its way past any of it.

API key or OAuth?

An API key if your client accepts custom headers (Claude Code, Cursor, VS Code, the bridges). OAuth 2.1 if it opens a consent screen instead (ChatGPT, claude.ai, Claude Desktop), which is also the only route for clients that cannot send headers. Neither one bypasses the guardrails.

Why do the tools answer forbidden after I connect?

Because MCP clients do not know our scope catalogue, and in the authorize step they almost always request the OIDC scopes only. Permissions come from the user-client binding instead: you pick them on the consent screen, and you can change them later under MCP Connections without reconnecting.

Is there a free plan?

Yes, and the MCP endpoint is on it. 3,000 emails a month, no credit card: an agent has to be able to try the product without asking anyone's permission.

Start with Sending

Give your agent something worth sending.

3,000 messages a month, free. No card. The MCP endpoint is on every plan, including this one.