Skip to main content
Glama
Sign In
Email Sending MCP

Email Sending MCP

by resend
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update Inbox Thread

update-inbox-thread

Mark an email thread read or unread, or move it to inbox, archive, spam, or trash.

Instructions

Purpose: Update one thread in a Resend inbox: mark it read or unread, or move it to another folder. At least one of read or folder is required.

NOT for: Tagging or untagging a thread with a label (use add-inbox-thread-labels and remove-inbox-thread-label), creating or deleting labels themselves (use create-inbox-label and remove-inbox-label), or deleting the thread (use remove-inbox-thread).

Returns: The thread's id, subject, folder, labels and read state after the update.

When to use: User asks to archive a thread, mark it read or unread, or move it to spam or trash. Moving a thread to trash schedules it for deletion in 30 days, the same as remove-inbox-thread. Moving a thread out of trash restores it and clears its deletion deadline. When both are passed, read is applied before folder, and the two are not atomic: if the folder move fails, the read change stays applied. Get the thread ID from list-inbox-threads.

Input Schema

NameRequiredDescriptionDefault
readNoMark every email in the thread as read (true) or unread (false).
folderNoFolder to move the thread to. Note that "sent" is not a valid destination: a thread can only be moved to inbox, archive, spam, or trash.
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. Changed3 schema fields changedv2.27.1
    • removedInput schema / properties / addLabelIds
      Removed value: -{
-  "anyOf": [
-    {
-      "minLength": 1,
-      "type": "string"
-    },
-    {
-      "items": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "maxItems": 10,
-      "minItems": 1,
-      "type": "array"
-    }
-  ],
-  "description": "ID of the label to apply to this thread, or an array of up to 10 label IDs. A label ID cannot be both added and removed in the same call. Use list-inbox-labels to find label IDs."
-}
    • 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."
    • removedInput schema / properties / removeLabelIds
      Removed value: -{
-  "anyOf": [
-    {
-      "minLength": 1,
-      "type": "string"
-    },
-    {
-      "items": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "maxItems": 10,
-      "minItems": 1,
-      "type": "array"
-    }
-  ],
-  "description": "ID of the label to take off this thread, or an array of up to 10 label IDs. The label itself is kept, and stays on every other thread that carries it. A label ID cannot be both added and removed in the same call. Use list-inbox-labels to find label IDs."
-}
  2. Addedv2.26.1

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: moving to trash schedules deletion in 30 days, moving out of trash restores the thread, and read/folder changes are applied in order without atomicity. It also explains the failure consequence if the folder move fails, which is important for an agent to reason about risk.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized with clear bold headings for Purpose, NOT for, Returns, and When to use. Despite covering several edge cases, every sentence earns its place and the critical constraints are front-loaded.

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 mutation tool with no output schema and only basic annotations, the description supplies the missing context: return fields, prerequisite thread ID source, restore semantics, and non-atomic failure behavior. Nothing essential for correct invocation 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 already 100%, so the baseline is 3. The description adds cross-parameter constraints not present in the schema: at least one of read or folder is required, read is applied before folder when both are passed, and the operations are not atomic. It also tells the agent where to get the thread ID.

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?

The description states a specific verb and resource: updating one Resend inbox thread to change read state or folder. It explicitly distinguishes this tool from sibling label operations and thread deletion, so an agent can route correctly without opening other tool definitions.

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?

It gives explicit when-to-use guidance (archive, mark read/unread, move to spam/trash) and names the alternatives for tagging, label management, and deletion. It also states the required combination rule: at least one of read or folder must be supplied.

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