@wraps.dev/mcp
MCP server for Amazon SES. Lets AI agents send email from your own AWS account, check domain verification and DKIM, look up the suppression list, and see whether the account is still in the SES sandbox.
Works with any SES account. Wraps adds send history and delivery events on top.
Runs locally via stdio. Your AWS credentials never leave your machine.
Prerequisites
- AWS credentials configured in your environment (a profile, SSO, or environment variables)
- An SES account in the region you point it at
- For
list_recent_sends and get_email_event_log only: the Wraps event pipeline, deployed with npx @wraps.dev/cli email init
- For the API-backed tools: a
WRAPS_API_KEY, or a session from wraps auth login
Tools
The API-backed rows ("Needs Wraps?" = Yes) need a Wraps API credential. See Wraps API tools.
Setup
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
Claude Code
Add to .mcp.json in your project root:
Set AWS_REGION to the region your Wraps stack is deployed in — SES identities are per-region, and a domain verified in another region reads as "not found". Claude Code inherits your shell's AWS environment, so you can drop the env block entirely if AWS_REGION (or a region in your active AWS profile) is already set there; the server fails at startup if neither supplies one.
Configuration
All configuration is via environment variables.
Wraps API tools
The tools marked "Needs Wraps? Yes (API key or wraps auth login)" call the Wraps API for your organization. They register at startup only when a credential is present. The server uses the first of these that it finds:
WRAPS_API_KEY, a wraps_... key.
- The unexpired session stored by
wraps auth login (or wraps selfhost login for a self-hosted instance).
With neither, only the AWS tools register. An expired or revoked credential does not stop startup; the call returns a tool error that names the fix.
Write tools need WRAPS_WRITE_ENABLED=true. Destructive tools also need confirm: true in the call, so set it only after the user has confirmed the change. When WRAPS_AGENT_ID is set (enforced mode), approve_agent_approval, reject_agent_approval, create_agent, kill_agent and set_agent_policy are not registered. list_agents stays registered.
Write Mode
send_email and the other write tools are disabled by default. Set WRAPS_WRITE_ENABLED=true to enable them. The from address must be a domain verified in your SES account.
Send guardrails
When write mode is enabled, the send_email tool can reach any SES-verified address by default. Use these env vars to restrict the agent's sending scope:
Note: Running with WRAPS_WRITE_ENABLED=true and no allowlist gives the agent unrestricted send capability to any address in your SES account.
Asking for missing input (elicitation)
If your MCP client supports elicitation, send_email asks you for input it is missing instead of failing. It never asks you to confirm an ordinary send, and it asks only after the write, recipient-count and allowlist checks above have passed.
- No sender. If the call has no
from and WRAPS_FROM_EMAIL is not set, the client prompts for the sender address.
- SES sandbox. If SES rejects the recipient because the account is in the sandbox, the client offers to send the message to the AWS mailbox simulator (
[email protected]) instead, to prove sending works. This happens once, and the simulator address must pass your recipient allowlist. The result says the message went to the simulator and not to the original recipient.
If you decline or cancel, or the client does not support elicitation, you get the same error as before. No setting is needed. Enforced mode does not use elicitation; its approvals stay with the operator.
Enforced mode (agent enforcer)
For agents provisioned via wraps email agent create, the MCP server runs in enforced mode. The agent's AWS credential can only invoke a customer-side enforcer Lambda — never SES directly. All policy (kill-switch, recipient allowlist, hourly/daily caps) is decided by that Lambda, so the local guardrails above are skipped.
When both are set, send_email invokes the enforcer instead of SES and returns a structured disposition rather than an error for policy outcomes:
sent — delivered, with messageId.
pending_approval — an operator must approve; poll check_send_status with the returned approvalId.
blocked — refused by policy (kill-switch, allowlist, or caps), with a reason.
Only transport or configuration failures are returned as errors. The check_send_status tool is registered only in enforced mode.
Enforced mode supports a single recipient per send. Pass one address as a string, or a one-element array; a to array with more than one recipient is rejected as an error (send one email per recipient). Note that WRAPS_ALLOWED_RECIPIENTS, WRAPS_ALLOWED_RECIPIENT_DOMAINS, WRAPS_MAX_RECIPIENTS, and WRAPS_ALLOW_FROM_OVERRIDE do not apply in enforced mode — recipient and sender policy is enforced entirely by the Lambda.
Replies and threading
Enforced-mode send_email accepts three optional fields for conversational sends —
an SDR sequence, a scheduling follow-up, anything where a human replies:
replyTo does not loosen sender pinning: from is still forced to the agent's own
verified identity, and pointing replyTo at a teammate is the intended use. The enforcer
rejects a replyTo carrying more than one address, and rejects inReplyTo/references
containing newlines or non-printable characters — both come back as a blocked disposition
with a reason, and neither consumes a rate-limit slot.
Requires an enforcer Lambda built from @wraps/core 2026-08-28 or later; against an older
enforcer the fields are ignored rather than erroring.
License
MIT