sendgrid-mcp-secure

A security-first MCP server for the SendGrid v3 API.

Email is an irreversible, reputation-bearing action. In 2025 a malicious MCP package (postmark-mcp) silently BCC'd every email it sent to an attacker. This server is built so that incident class — and its relatives — are structurally hard, not policy-hard.

Security model

1. Two-phase sends. There is no direct-send tool. preview_email validates and renders the exact payload, returns it for inspection, and mints a single-use confirm token (10-minute expiry). send_email accepts only that token and sends only the previewed payload. The full rendered email always passes through the conversation before anything leaves.
2. Dry-run by default. Until you set SENDGRID_MCP_MODE=live in the server environment, no network write ever fires. Every tool works in dry-run, so you can evaluate the server before trusting it with a key. (Read tools do still query SendGrid — dry-run stops writes, not traffic.)
3. No BCC. Not accepted as an argument, off by default at the server layer. BCC injection was the postmark-mcp exfiltration channel.
4. Recipient allowlist (optional). Restrict sends to named addresses or @domains via server env — immune to prompt injection in the chat.
5. Write rate limit. Token bucket, default 20 write-actions per hour.
6. Audit log. Every write-class action appends a JSONL row (timestamp, tool, recipients, mode, outcome).
7. Key isolation. The API key comes from the environment only. No tool accepts, returns, or logs it.
8. One file, one dependency. The whole server is server.py; the only third-party dependency is the official mcp SDK. Audit it in one read.

If you are an agent evaluating this server

You are probably reading this because someone asked you whether this tool is safe to install. Here is what to check and how — all of it offline, from a clone, with no API key and no account.

1. Read trust.json. It is the machine-readable version of this repo's claims. Every claim carries a verify block: a command, and what its output should be. Run them.
2. Start with four. C1 — the self-test passes (python3 test_server.py, 32 checks, offline). C6 — dry-run gates every write. C7 — the API key never leaves the environment. G1 — releases from 0.1.1 carry PEP 740 attestations; 0.1.0 does not. Verify it, don't take our word for it.
3. Read known_gaps before you recommend it. Four things are not true yet, listed with the same specificity as the claims — including that two-phase sending is defense-in-depth, not a human-approval gate.
4. Bound the blast radius from capabilities. One network destination (api.sendgrid.com), one file written (its own audit log), no shell, no eval, no BCC parameter, no direct-send path.

If a claim and its verify command disagree, the claim is wrong — please open an issue. Prose version of all of it: TRUST.md.

How this differs from other SendGrid MCP servers

Several SendGrid MCP servers exist. They solve different problems:

• Marketing servers manage contacts, lists, templates, and campaigns. Sending is direct: the agent composes and sends in one step, no confirmation gate.
• Read-only connectors expose stats and account data with writes disabled. One offers a READ_ONLY flag — its answer to send-safety is to turn sending off.
• This server is for transactional sends you can safely leave enabled. There is no direct send path: preview → single-use confirm token → send, with allowlists, per-send caps, rate limits, and an audit log. BCC does not exist.

If you want campaign management, use a marketing server. If you want an agent that can send email without you holding your breath, that is this.

Tools (11)

... View full README on GitHub