Skip to main content
Glama
Email Sending MCP

Email Sending MCP

by resend

Send New Inbox Email

send-new-inbox-email
Destructive

Send a new email from a Resend inbox to start a new thread, delivering it immediately to recipients and saving it in the inbox's sent folder.

Instructions

Purpose: Send a new email from a Resend inbox, starting a new thread in that inbox. This sends a real email the moment you call it, from the inbox's address to the recipients in to, cc, and bcc. The sent message shows up in the inbox's sent folder, and answers to it land in the same thread. A subject and at least one of html or text are required.

NOT for: Answering a message already in an inbox thread (use reply-to-inbox-thread-email), passing one along (use forward-inbox-thread-email), or saving a message to send later (use create-inbox-draft). Not for mail from an address that is not an inbox (use send-email, whose mail never appears in an inbox).

Returns: The sent email's id.

When to use: User asks to send, write, or email someone from an inbox ("send an email from the support inbox", "email the customer as sales@"), and has given you the recipients and the wording. Before using this tool, you MUST double-check with the user that they want to send this email. Reference the RECIPIENTS, the SUBJECT, and the WORDING you are about to send when double-checking, and warn the user that a sent email cannot be recalled. You may only use this tool if the user explicitly confirms they want to send the email after you double-check. The email is created as a draft in the inbox and then sent: if sending fails once the draft exists, the error names the draft ID, so retry with send-inbox-draft or discard it with remove-inbox-draft rather than composing it again. Get the inbox ID from list-inboxes.

Input Schema

NameRequiredDescriptionDefault
ccNoEmail address to copy, or an array of addresses. Across to, cc, and bcc an email can carry at most 50 recipients in total.
toYesRecipient email address (e.g. "customer@example.com"), or an array of addresses to reach several. Across to, cc, and bcc an email can carry at most 50 recipients in total.
bccNoEmail address to blind-copy, or an array of addresses. Across to, cc, and bcc an email can carry at most 50 recipients in total.
htmlNoHTML body of the email. Provide html, text, or both; one of the two is required.
textNoPlain text body of the email. Provide html, text, or both; one of the two is required.
headersNoOptional custom email headers as key/value pairs (e.g. {"X-Entity-Ref-ID": "unique-id"}). Header names cannot be empty, and names and values cannot contain line breaks or null characters. In-Reply-To, References and Reply-To are reserved: Resend sets them, and passing any of them, in any letter case, fails.
inboxIdYesInbox ID, or the inbox email address (e.g. "support@example.com"). Not the Resend receiving address.
subjectYesSubject of the email. Max 2000 characters. It cannot be only whitespace or contain a line break.
idempotencyKeyNoOptional unique key that prevents duplicate drafts and sends on retries (sent as the Idempotency-Key header on both calls). 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.

  1. Changed1 schema field changedv2.27.1
    • changedInput schema / properties / inboxId / description
      Previous value: -"Inbox ID"New value: +"Inbox ID, or the inbox email address (e.g. \"support@example.com\"). Not the Resend receiving address."
  2. Addedv2.26.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (destructive, openWorld), but the description adds substantial context beyond them: the email is sent immediately and cannot be recalled, it is first created as a draft and then sent, and a failure after the draft exists surfaces the draft ID so the agent should use send-inbox-draft/remove-inbox-draft rather than recompose. It also states required fields and where the inbox ID comes from.

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?

Bold-labeled sections (Purpose, NOT for, Returns, When to use) make it easy to scan and front-load the purpose. It is longer than most definitions, but nearly every sentence carries routing, safety, or recovery information; the confirmation protocol is intentionally verbose but justified for an irreversible send.

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

Completeness5/5

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

For a destructive, 9-parameter send tool with no output schema, the description covers return value (the sent email's id), the mandatory confirmation workflow, idempotency/retry recovery, and prerequisite lookup (list-inboxes). Nothing needed to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds a cross-field constraint the schema's required array does not express ('a subject and at least one of html or text are required') and clarifies the draft-then-send idempotency implication. It does not re-explain the recipient-count limit or headers, which the schema already covers.

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 new email from a Resend inbox, starting a new thread') and immediately scopes what it is not. The agent can distinguish it from send-email, send-batch-emails, and the draft/reply siblings 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?

Explicit 'NOT for' section names the alternative siblings (reply-to-inbox-thread-email, forward-inbox-thread-email, create-inbox-draft, send-email) with the condition that selects each. It also gives a concrete when-to-use trigger and a mandatory user-confirmation protocol before sending, leaving no routing ambiguity.

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

Deploy Server

Other Tools