Email Sending MCP

Overview Schema Source Related Servers Discussions Admin

Send Email

send-email

Purpose: Send a single transactional email to one or more recipients immediately (or schedule it). Use for one-off messages, notifications, and direct replies.

Instructions

Purpose: Send a single transactional email to one or more recipients immediately (or schedule it). Use for one-off messages, notifications, and direct replies.

NOT for: Sending the same email to a whole list/audience (use create-broadcast + send-broadcast). Not for managing contacts or audiences. Not for sending from a Resend inbox's address: mail sent here never appears in the inbox, so use send-new-inbox-email to start a thread from an inbox and reply-to-inbox-thread-email to answer one.

Returns: Send confirmation and email ID.

When to use:

User wants to "send an email" to specific people (names or addresses)
One-off messages: password reset, order confirmation, receipt, alert
User says "email this to X", "notify them", "send a message to..."
Scheduling a single email for later

Workflow: Get recipient(s) and content from user → send-email. Use list-emails or get-email to check delivery status afterward.

Key trigger phrases: "Send an email", "Email this to", "Notify", "Send a message", "Reply to them", "Schedule an email"

Input Schema

TableJSON Schema

Name	Required	Description
`cc`	No	Optional array of CC email addresses. You MUST ask the user for this parameter. Under no circumstance provide it yourself
`to`	Yes	Array of recipient email addresses (1-50 recipients)
`bcc`	No	Optional array of BCC email addresses. You MUST ask the user for this parameter. Under no circumstance provide it yourself
`from`	Yes	Sender email address (e.g. "onboarding@resend.com" or "Acme <onboarding@resend.com>"). You MUST ask the user for this parameter. Under no circumstance provide it yourself
`html`	No	HTML email content. When provided, the plain text argument MUST be provided as well.
`tags`	No	Array of custom tags for tracking/analytics. Each tag has a name and value.
`text`	Yes	Plain text email content
`headers`	No	Optional custom email headers as key/value pairs (e.g. {"List-Unsubscribe": "<https://example.com/unsubscribe>", "X-Entity-Ref-ID": "unique-id"}). Use for one-click unsubscribe, preventing Gmail threading, or other MIME headers Resend accepts.
`replyTo`	No	Optional email addresses for the email readers to reply to (e.g. "support@example.com" or "Support Team <support@example.com>"). You MUST ask the user for this parameter. Under no circumstance provide it yourself
`subject`	Yes	Email subject line
`topicId`	No	Topic ID for subscription-based sending. When set, the email respects contact subscription preferences for this topic.
`attachments`	No	Array of file attachments. Each needs filename plus one of: filePath, url, or content. Prefer url or content on a remote server, where filePath is disabled by default. Max 40MB total.
`scheduledAt`	No	Optional parameter to schedule the email. This uses natural language. Examples would be 'tomorrow at 10am' or 'in 2 hours' or 'next day at 9am PST' or 'Friday at 3pm ET'.
`idempotencyKey`	No	Optional unique key that prevents duplicate sends on retries (sent as the Idempotency-Key header). Use the same key when retrying the same logical email; use a new key for a different email. Must be 1-256 characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.26.1Oct 14, 2026

changedInput schema / properties / attachments / description

Previous value: -"Array of file attachments. Each needs filename plus one of: filePath, url, or content. Max 40MB total."New value: +"Array of file attachments. Each needs filename plus one of: filePath, url, or content. Prefer url or content on a remote server, where filePath is disabled by default. Max 40MB total."

changedInput schema / properties / attachments / items / properties / filePath / description

Previous value: -"Local file path to read and attach"New value: +"Path to a file on the machine that runs this MCP server. The server can restrict or disable local file reads; use url or content if it does."

Changed7 schema fields changedv2.12.0Aug 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / headers

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Optional custom email headers as key/value pairs (e.g. {\"List-Unsubscribe\": \"<https://example.com/unsubscribe>\", \"X-Entity-Ref-ID\": \"unique-id\"}). Use for one-click unsubscribe, preventing Gmail threading, or other MIME headers Resend accepts.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedInput schema / properties / idempotencyKey / description

Previous value: -"Optional unique key that prevents duplicate sends on retries (sent as the Idempotency-Key header). Use the same key when retrying the same logical email; use a new key for a different email. Max 256 characters."New value: +"Optional unique key that prevents duplicate sends on retries (sent as the Idempotency-Key header). Use the same key when retrying the same logical email; use a new key for a different email. Must be 1-256 characters."

addedInput schema / properties / idempotencyKey / minLength
```
Added value: +1
```

changedInput schema / properties / replyTo / description

Previous value: -"Optional email addresses for the email readers to reply to. You MUST ask the user for this parameter. Under no circumstance provide it yourself"New value: +"Optional email addresses for the email readers to reply to (e.g. \"support@example.com\" or \"Support Team <support@example.com>\"). You MUST ask the user for this parameter. Under no circumstance provide it yourself"

removedInput schema / properties / replyTo / items / format
```
Removed value: -"email"
```

removedInput schema / properties / replyTo / items / pattern

Removed value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

Changed4 schema fields changedv2.11.0Jul 10, 2026

changedInput schema / properties / from / description

Previous value: -"Sender email address. You MUST ask the user for this parameter. Under no circumstance provide it yourself"New value: +"Sender email address (e.g. \"onboarding@resend.com\" or \"Acme <onboarding@resend.com>\"). You MUST ask the user for this parameter. Under no circumstance provide it yourself"

removedInput schema / properties / from / format
```
Removed value: -"email"
```

removedInput schema / properties / from / pattern

Removed value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Optional unique key that prevents duplicate sends on retries (sent as the Idempotency-Key header). Use the same key when retrying the same logical email; use a new key for a different email. Max 256 characters.",
+  "maxLength": 256,
+  "type": "string"
+}

First observedv2.10.0Jul 4, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it does supply real behavioral context: scheduling is supported, the return value is 'send confirmation and email ID', and crucially that mail sent here never appears in the inbox. It omits auth/permission requirements, rate limits, and failure modes, which keeps it from a 5 under a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded with bolded section headers (Purpose, NOT for, Returns, When to use, Workflow), so an agent can skim. It is longer than strictly necessary, and the 'Key trigger phrases' block partly duplicates the 'When to use' bullets, which costs some conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with nested objects and no output schema, the description covers purpose, alternatives, workflow, and a brief return note. Parameter detail is delegated to the fully-covered schema, and it gives just enough return information to orient the agent, though a richer return description would help since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 14 parameters (recipients, from, html/text, attachments, scheduling, idempotency). The description adds little parameter-level detail beyond noting recipients and scheduling, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Send a single transactional email to one or more recipients') plus scope ('immediately or schedule it'). It explicitly distinguishes itself from siblings by naming create-broadcast/send-broadcast, the contact/audience tools, and send-new-inbox-email/reply-to-inbox-thread-email. An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a dedicated 'NOT for' section naming exact alternatives and the conditions that select them (bulk sending, contact management, inbox-thread sending). Adds concrete when-to-use bullets, a workflow sequence, and trigger phrases. This is about as explicit as when/when-not/alternatives guidance gets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Send Email

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools