Skip to main content
Glama
resend

Email Sending MCP

by resend

Reply to Inbox Thread Email

reply-to-inbox-thread-email
Destructive

Purpose: Reply to one message in a Resend inbox thread. This sends a real email the moment you call it, from the inbox's address to the author of the message, or to everyone on it with replyAll, plus anyone you add in cc or bcc.

Instructions

Purpose: Reply to one message in a Resend inbox thread. This sends a real email the moment you call it, from the inbox's address to the author of the message, or to everyone on it with replyAll, plus anyone you add in cc or bcc. At least one of html or text is required.

NOT for: Passing the message along to someone new without answering it (use forward-inbox-thread-email), or starting a new conversation from the inbox (use send-new-inbox-email).

Returns: The sent email's id.

When to use: User asks to reply to, answer, or follow up on a message in an inbox thread, and has given you the wording. Before using this tool, you MUST double-check with the user that they want to send this reply. Reference the WORDING you are about to send and the SUBJECT of the thread you are answering when double-checking, and warn the user that a reply cannot be undone: a sent email cannot be recalled. You may only use this tool if the user explicitly confirms they want to send the reply after you double-check. You do not choose who the reply answers: by default the reply goes only to the author of the message you answer, at its Reply-To address if it has one. If the inbox sent that message, the reply goes to the people it was sent to. Set replyAll to true when the user wants to reply to everyone on that message. Pass cc or bcc only to add recipients the user named. Mention in the double-check whether you reply to the author only or to everyone, and any cc or bcc recipients you add. A reply can reach at most 50 recipients in total, counted after replyAll adds everyone on the message. Name any attachments in the double-check. Omit subject to use the thread's. Get the emailId from get-inbox-thread.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoEmail address to copy on the reply, or an array of addresses. Not copied from the message you answer. With replyAll, these join the copied recipients, without duplicates.
bccNoEmail address to blind-copy on the reply, or an array of addresses. Not copied from the message you answer, even with replyAll.
htmlNoHTML body of the reply. Provide html, text, or both. One of the two is required.
textNoPlain text body of the reply. Provide html, text, or both. One of the two is required.
emailIdYesID of the message being replied to. 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 reply. Omit to use the thread's subject, prefixed with "Re:", which is usually what you want. Max 2000 characters. It cannot be only whitespace or contain a line break.
replyAllNoReply to everyone on the message instead of only its author. For a message the inbox received, the reply goes to the author as usual and copies the message's other to recipients and its cc recipients. For a message the inbox sent, it goes to its Reply-To when that is not the inbox's address and copies its to and cc recipients; otherwise it goes to its to recipients and copies its cc recipients. The inbox's own address is left out and duplicates are removed. Defaults to false (author only).
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. Up to 10 files. The content of all files can total at most 25 MB. 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 supply destructive/openWorld hints, and the description adds substantial context beyond them: the send is immediate and irreversible ('cannot be recalled'), the 50-recipient ceiling counted after replyAll, default reply-target routing rules, and the idempotency-key duplicate-suppression behavior. This is rich behavioral disclosure that the annotations alone would not 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?

Front-loads Purpose, then NOT for, Returns, and When to use with bold labels, making it easy to scan. It is long, but for an irreversible send tool with safety gating each sentence carries weight; the length is justified rather than padded.

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 12-parameter, mutation tool with nested attachments and no output schema, it covers the critical behaviors: confirmation requirement, recipient limits, routing defaults, attachment constraints, and the returned value (email id). Nothing an agent needs to call it safely appears to be 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 routing meaning not obvious from the schema alone: 'You do not choose who the reply answers' and the default author-only vs replyAll audience behavior, plus the 'omit subject to use the thread's' guidance. It goes modestly beyond the already-complete schema.

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?

Opens with a specific verb+resource ('Reply to one message in a Resend inbox thread') and immediately notes it sends a real email. It explicitly names the two sibling tools it is not (forward-inbox-thread-email, send-new-inbox-email), so an agent can disambiguate 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?

Gives explicit when-to-use ('user asks to reply to, answer, or follow up'), explicit NOT-for cases with the correct alternatives, and a mandatory user-confirmation precondition. This is textbook routing guidance.

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