Skip to main content
Glama
Sign In
Email Sending MCP

Email Sending MCP

by resend
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List Inbox Thread Emails

list-inbox-thread-emails
Read-only

List emails in a Resend inbox thread, oldest first, without bodies, for paging long threads. Returns IDs, direction, participants, subject, read state, and attachment counts.

Instructions

Purpose: List the emails in one Resend inbox thread, oldest first, without their bodies.

NOT for: Reading a message's body (use get-inbox-thread-email). Not for the thread's folder, labels or read state (use get-inbox-thread, which returns them with the first page of emails).

Returns: For each email: its email ID, direction (inbound or outbound), from, to, subject, received_at, read state, and how many attachments it carries.

When to use: You need the next page of a long thread after get-inbox-thread, or only the emails of a thread. 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". This endpoint is paginated: when more emails exist, pass the last email's ID back as "after" for the next, newer page. When paging backward with "before", pass the first email's ID back as "before".

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: 20, 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 readOnly/destructive/openWorld, so the safety profile is covered; the description adds real value on top by disclosing ordering (oldest first), body exclusion, and the forward/backward pagination mechanics. It stops short of stating auth or rate-limit behavior, but for a read-only list tool this is close to complete.

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 section headers (Purpose / NOT for / Returns / When to use) front-load the key information, and each sentence carries actionable content. Slightly long, with the pagination paragraph doing double duty with the schema, but no wasted filler.

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 compensates by enumerating the returned fields per email. Combined with the routing guidance and pagination contract, an agent has everything needed to call and chain this tool 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%, so baseline is 3, but the description goes beyond it by explaining the cross-tool identity semantics ("A message's ID IS the email ID" taken by get/reply/forward) and by restating the after/before paging contract in operational terms. That is meaning the schema's per-field text does not supply.

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 ("List the emails in one Resend inbox thread") and immediately scopes it ("oldest first, without their bodies"). It explicitly names the siblings it is not (get-inbox-thread-email, get-inbox-thread), so an agent can distinguish it without opening 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?

Provides an explicit "NOT for" list with the correct alternative for each case, plus a "When to use" clause covering the pagination-continuation and thread-listing scenarios. Nothing about tool selection is left to inference.

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