Skip to main content
Glama
resend

Email Sending MCP

by resend

Forward Inbox Thread Email

forward-inbox-thread-email
Destructive

Purpose: Forward one message from a Resend inbox thread to someone else. This sends a real email the moment you call it, from the inbox's address to the recipients named in "to", "cc" and "bcc".

Instructions

Purpose: Forward one message from a Resend inbox thread to someone else. This sends a real email the moment you call it, from the inbox's address to the recipients named in "to", "cc" and "bcc".

NOT for: Answering the sender (use reply-to-inbox-thread-email, which answers the message's author, or everyone on it with replyAll). Not for starting a new conversation from the inbox (use send-new-inbox-email).

Returns: The sent email's id.

When to use: User asks to forward a message in an inbox thread, pass it along, or loop someone in on it. Before using this tool, you MUST double-check with the user that they want to forward this message. Reference the RECIPIENTS, including any cc and bcc, and the SUBJECT when double-checking, and warn the user that forwarding cannot be undone: a sent email cannot be recalled, and every recipient keeps the original message. You may only use this tool if the user explicitly confirms they want to forward the message after you double-check. "to" is the only body field required: html and text are an optional note of your own, because the original message is carried either way. Across to, cc and bcc a forward can reach at most 50 recipients in total. The original message's attachments are sent with the forward; name any attachments you add in the double-check. A message whose original attachment was sent from a URL cannot be forwarded. Get the emailId from get-inbox-thread.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoEmail address to copy on the forward, or an array of addresses.
toYesRecipient email address to forward to (e.g. "teammate@example.com"), or an array of recipient email addresses to forward to several.
bccNoEmail address to blind-copy on the forward, or an array of addresses.
htmlNoOptional HTML note to add above the forwarded message. This does not replace the original body: the message being forwarded is carried along either way.
textNoOptional plain text note to add above the forwarded message. This does not replace the original body: the message being forwarded is carried along either way.
emailIdYesID of the message being forwarded. This is the "id" get-inbox-thread returns for each message in the thread.
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
subjectNoSubject for the forwarded email. Omit to use the thread's subject, prefixed with "Fwd:". Max 2000 characters. It cannot be only whitespace or contain a line break.
threadIdYesThread ID
attachmentsNoFiles to attach. Each one needs filename plus content or url. An empty file or a blocked file type (such as .exe) is rejected. The forward also sends the attachments of the original message, and they share one limit: up to 10 files and at most 25 MB of content together. A url file counts toward the 10 files only, because it is fetched when the email is sent. The whole email, encoded, can be at most 40 MB.
idempotencyKeyNoOptional 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.

  1. Addedv2.26.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare destructive/openWorld; the description goes far beyond by disclosing the irreversible side effect (a sent email cannot be recalled, recipients keep the original message), the 50-recipient aggregate cap, the shared 10-file/25 MB attachment ceiling, and the URL-sourced-attachment limitation. This is exactly the behavioral context annotations cannot convey.

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 headers (Purpose, NOT for, Returns, When to use) front-load the critical routing and safety information before the operational details. The text is dense and long, but with 12 parameters and an irreversible action nearly every sentence carries a constraint an agent needs.

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?

No output schema exists, yet the return value is stated (the sent email's id). Prerequisites, recipient caps, attachment limits, header restrictions and the confirmation gate are all covered, leaving nothing an agent needs to call this destructive tool safely.

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 baseline is 3, but the description adds real meaning beyond the schema: that html/text are non-replacing notes because the original body is carried regardless, that to/cc/bcc share one 50-recipient budget, that subject defaults to "Fwd:" plus the thread subject, and that attachments share a combined limit with the original message's files.

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 ("Forward one message from a Resend inbox thread to someone else") and immediately names what it is not, distinguishing it from reply-to-inbox-thread-email and send-new-inbox-email by name. An agent can select it without opening sibling schemas.

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" block names two alternatives and the conditions that select them (answering the sender vs. starting a new conversation), plus a "When to use" section with the user's likely phrasing. The mandatory double-check precondition is stated as a hard gate.

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