Skip to main content
Glama
Sign In
Email Sending MCP

Email Sending MCP

by resend
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Inbox Thread

get-inbox-thread
Read-only

Retrieve a single email thread and its message metadata, oldest first, to view a conversation or obtain email IDs for replies or forwarding.

Instructions

Purpose: Get one thread in a Resend inbox: the thread itself plus the metadata of its emails, oldest first.

NOT for: Reading a message's body. This tool returns no html or text, because a whole conversation's bodies would flood the response. Use get-inbox-thread-email for one message's body.

Returns: The thread's id, subject, folder, labels and read state, then for each email its email ID, direction (inbound or outbound), from, to, subject, received_at, read state, and how many attachments it carries. Emails are paginated: when more exist, pass the last email's ID back as "after". When paging backward with "before", pass the first email's ID back as "before".

When to use: User wants to see a conversation, or you need a message's email ID. A message's ID IS the email ID that get-inbox-thread-email, reply-to-inbox-thread-email, and forward-inbox-thread-email take as their "emailId". Get the thread ID from list-inbox-threads or search-inbox-threads.

Input Schema

NameRequiredDescriptionDefault
afterNoEmail ID after which to retrieve more (the next, newer page). Cannot be used with "before". An ID that is not a message of this thread returns a 404.
limitNoNumber of emails to retrieve. Default: 100, Max: 100, Min: 1. Emails are oldest first.
beforeNoEmail ID before which to retrieve more (the previous, older page). Cannot be used with "after". An ID that is not a message of this thread returns a 404.
inboxIdYesInbox ID, or the inbox email address (e.g. "support@example.com"). Not the Resend receiving address.
threadIdYesThread ID

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.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered; the description still adds real behavioral detail by disclosing that no html/text bodies are returned and by describing the oldest-first return shape. It stops short of stating permission requirements or rate limits, so a 4 rather than a 5.

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?

Markdown headers (Purpose / NOT for / Returns / When to use) front-load the key facts, and the negated use case appears before the return detail. It is longer than strictly necessary in the Returns block, but nearly every sentence carries operational information.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly - thread fields, per-email fields, ordering, and pagination. Combined with the usage routing, an agent has everything needed to call it correctly.

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%, which sets the baseline at 3. The description goes beyond the schema by explaining the actual paging protocol ('pass the last email's ID back as after', 'pass the first email's ID back as before'), turning generic cursor parameters into an actionable procedure.

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 ('Get one thread in a Resend inbox: the thread itself plus the metadata of its emails') and immediately distinguishes itself from the sibling get-inbox-thread-email by refusing to return message bodies. An agent can tell it apart from list-inbox-threads and get-inbox-thread-email without opening a 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' clause names the alternative (get-inbox-thread-email) and the reason. 'When to use' gives two concrete triggers and tells the agent where the required IDs come from (list-inbox-threads / search-inbox-threads), plus the ID relationship to reply/forward tools.

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