email

@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

Tools

Tool	Description	Needs Wraps?	Write?
send_email	Send a transactional email via your SES account	No	Yes — requires WRAPS_WRITE_ENABLED=true
verify_domain_status	Check verification and DKIM status of a sending domain	No	No
list_suppressions	List addresses on your SES suppression list (paginated, with an explicit truncation notice), or check one address exactly with email	No	No
get_setup_status	Check whether the account is in the SES sandbox, and get the next step toward a first send	No	No
estimate_cost	Estimate monthly Wraps + AWS cost for a send volume, including which SES pricing plan the account is on. No AWS credentials needed	No	No
list_recent_sends	List recent sends from your email history	Yes	No
get_email_event_log	Get the full delivery event log for a message (Send, Delivery, Bounce, Complaint, Open, Click)	Yes	No
check_send_status	Poll the outcome of a pending_approval send by approvalId (enforced mode only)	Yes	No

Setup

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "wraps": {
      "command": "npx",
      "args": ["-y", "@wraps.dev/mcp"],
      "env": {
        "AWS_REGION": "us-east-1",
        "AWS_PROFILE": "your-aws-profile"
      }
    }
  }
}

Claude Code

Add to .mcp.json in your project root:

{
  "mcpServers": {
    "wraps": {
      "command": "npx",
      "args": ["-y", "@wraps.dev/mcp"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

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.

Variable	Required	Default	Description
AWS_REGION	Yes*	—	AWS region where your Wraps stack is deployed. *Required unless your active AWS profile (~/.aws/config) supplies a region — the server resolves AWS_REGION, then AWS_DEFAULT_REGION, then the profile, and errors at startup if none of them do.
WRAPS_HISTORY_TABLE_NAME	No	wraps-email-history	DynamoDB table name for email history
WRAPS_ACCOUNT_ID	No	auto-detected via STS	Your AWS account ID (skip STS call if set)
WRAPS_WRITE_ENABLED	No	false	Set to true to enable send_email
WRAPS_FROM_EMAIL	No	—	Default from address for send_email

Write Mode

send_email is disabled by default. Set WRAPS_WRITE_ENABLED=true to enable it. The from address must be a domain verified in your SES account.

{
  "mcpServers": {
    "wraps": {
      "command": "npx",
      "args": ["-y", "@wraps.dev/mcp"],
      "env": {
        "AWS_REGION": "us-east-1",
        "WRAPS_WRITE_ENABLED": "true",
        "WRAPS_FROM_EMAIL": "[email protected]"
      }
    }
  }
}

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:

Variable	Default	Description
WRAPS_ALLOWED_RECIPIENTS	— (no restriction)	Comma-separated exact addresses the agent may send to. If set, any address not in this list (or WRAPS_ALLOWED_RECIPIENT_DOMAINS) is rejected.
WRAPS_ALLOWED_RECIPIENT_DOMAINS	— (no restriction)	Comma-separated domains (e.g. company.com,partner.org) the agent may send to. Combined with WRAPS_ALLOWED_RECIPIENTS; a recipient is allowed if it matches either list. Matching is exact: example.com allows [email protected] but NOT subdomains like [email protected] — list each subdomain explicitly.
WRAPS_MAX_RECIPIENTS	50	Maximum number of recipients per send_email call.
WRAPS_ALLOW_FROM_OVERRIDE	false	Set to true to let the agent supply a from address that differs from WRAPS_FROM_EMAIL. When false (default), the caller-supplied from is rejected if it does not match the configured address.

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.

Variable	Required	Description
WRAPS_AGENT_ID	Yes (for enforced mode)	The agent's ID. Enables enforced mode when set together with the enforcer function.
WRAPS_AGENT_ENFORCER_ARN	Yes (for enforced mode)	Qualified per-agent alias ARN of the customer's wraps-agent-enforcer Lambda (arn:aws:lambda:<region>:<acct>:function:wraps-agent-enforcer:agent-<agentId>). A bare function name or unqualified ARN invokes $LATEST, which the enforcer treats as a platform caller and blocks agent sends.

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:

Field	Purpose
replyTo	A single address where a human's reply should land. Without it, replies reach the agent's own mailbox — right for support@, wrong when a person should pick the conversation up.
inReplyTo	Message-ID of the message being replied to, e.g. <[email protected]>.
references	Space-separated Message-ID chain of the conversation so far. Set it alongside inReplyTo so a follow-up threads instead of arriving as an orphan.

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