sendgrid-mcp-secure
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENDGRID_API_KEY | No | Your SendGrid API key. Required for live mode. | |
| SENDGRID_MCP_MODE | No | Set to 'live' to enable real sends, 'dry-run' for dry-run mode. | dry-run |
| SENDGRID_MCP_ALLOW_BCC | No | Set to '1' to allow BCC (not recommended). | off |
| SENDGRID_MCP_AUDIT_LOG | No | Path to the audit log file. | ~/.sendgrid-mcp/audit.jsonl |
| SENDGRID_MCP_MAX_RECIPIENTS | No | Maximum number of recipients per send (to + cc). | 10 |
| SENDGRID_MCP_WRITES_PER_HOUR | No | Maximum number of write actions per hour. | 20 |
| SENDGRID_MCP_RECIPIENT_ALLOWLIST | No | Comma-separated list of allowed recipient emails and/or @domains. | any |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preview_emailA | Validate and render an email WITHOUT sending it. Returns the exact payload that would go to SendGrid plus a single-use confirm_token (valid 10 minutes). Sending requires passing that token to send_email — there is no direct-send path. BCC is not accepted by design. |
| send_emailA | Send the email previously rendered by preview_email. Accepts ONLY a confirm token — the payload cannot be altered between preview and send. Tokens are single-use and expire after 10 minutes. In dry-run mode (the default) this simulates and audits but sends nothing. |
| add_suppressionB | Add an address to a suppression list (default: global unsubscribes). Suppressing is the SAFE direction — it stops future sends to the address. |
| remove_suppressionA | Remove an address from a suppression list. DANGEROUS direction — it re-enables sending to someone who bounced or unsubscribed, which can be a compliance violation. Requires confirm=true, is rate-limited, and audited. |
| list_templatesB | List transactional email templates (dynamic + legacy). |
| get_templateA | Fetch one template with its versions (subject + content preview). |
| get_email_statsA | Global email stats (requests/delivered/opens/clicks/bounces/spam) from start_date (YYYY-MM-DD). aggregated_by: day|week|month. |
| list_suppressionsB | List a suppression list: unsubscribes|bounces|blocks|spam_reports|invalid_emails. |
| check_suppressionA | Check whether an address appears on any suppression list. Run this before drafting mail to someone — sending to suppressed addresses hurts deliverability and may violate consent. |
| get_domain_authA | List authenticated sending domains and their DNS validity — the first thing to check when deliverability drops. |
| server_statusA | This server's security posture: mode, rate-limit remaining, allowlist, caps, audit-log path, and whether an API key is present (never the key). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool targets a distinct operation: preview vs send, add vs remove suppression, list vs get template, list vs check suppression. Even the two-step email flow is clearly separated by intent and confirm token. No overlapping purposes.
Most tools follow verb_noun (preview_email, add_suppression, list_templates, check_suppression) with consistent use of list/get for collections vs single items. 'server_status' is the only deviation, using noun_noun instead of a verb.
11 tools is well within the ideal 3-15 range. Each tool covers a meaningful part of email sending, suppression management, templates, stats, and domain auth. The count feels intentional and scoped, not padded or sparse.
Covers the core workflows: preview-and-send, suppression management (add/remove/list/check), template inspection, stats, and domain auth. Minor gaps exist (no template creation/update/delete, no per-template stats), but they don't block the primary use case.