Multi Mail

Restore a thread from the trash

threads_untrash

Idempotent

Bring one thread, or one message of it, back out of the trash. A Gmail connected by Google sign-in brings it back with every label it carried. A Gmail mailbox whose provider is imap puts a draft back in its drafts, the owner's own mail in sent mail and the rest in the inbox, with every label it carried, each message keeping its id. An Outlook mailbox and any other mailbox whose provider is imap put a message threads_trash moved there back in the folder that move took it from - the latest such move, within 30 days, while that folder is still there outside the trash - and any other message by that same rule; each message they bring back names the folder it went to as restoredTo, and in a mailbox whose provider is imap the new id it took. With ids in place of id it takes 2 to 100 at once under one call's time, counted as one action: each thread it reached is answered under threads - done; notDone, saying why; or possiblyDone, moved in part or asked with no answer back, which threads_get - or messages_get for a message - reads to check - and each it did not reach, its time spent, its connection lost or the mailbox refusing it whole, is left untouched under notReached, for the same call again.

Input Schema

Name	Required	Description
`id`	No	The threadId a search or a read answered, or with scope message the message's id.
`ids`	No	2 to 100 threadIds - or with scope message message ids - in place of id, acted on in one call.
`scope`	No	thread, the default, acts on the whole thread; message acts on that one message alone.
`mailbox`	Yes	The mailbox's name or its email address.

Output Schema

Name	Required	Description
`id`	No
`threads`	No	Each thread the call reached, with ids.
`labelIds`	No
`messages`	No
`newestOnly`	No	The folders whose provider showed only their newest messages, each with how many it showed: every one holds more, and nothing before those was read, searched, counted or acted on, so finding nothing there says nothing of the rest.
`notReached`	No	The ids the call did not reach - its time ran out, its connection to the mailbox was lost, or the mailbox refused it whole, as the thread that met the refusal says - each left untouched, for the same call again.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedOutput schema / properties / newestOnly

Added value: +{
+  "description": "The folders whose provider showed only their newest messages, each with how many it showed: every one holds more, and nothing before those was read, searched, counted or acted on, so finding nothing there says nothing of the rest.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "folder": {
+        "type": "string"
+      },
+      "shown": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "folder",
+      "shown"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / threads / items / properties / newestOnly

Added value: +{
+  "description": "The folders whose provider showed only their newest messages, each with how many it showed: every one holds more, and nothing before those was read, searched, counted or acted on, so finding nothing there says nothing of the rest.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "folder": {
+        "type": "string"
+      },
+      "shown": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "folder",
+      "shown"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedNov 2, 2026

changedOutput schema / properties / notReached / description

Previous value: -"The ids the call did not reach - its time ran out, its connection to the mailbox was lost, or the mailbox refused it whole, as the thread that met the refusal says - each left untouched: make the same call again with them."New value: +"The ids the call did not reach - its time ran out, its connection to the mailbox was lost, or the mailbox refused it whole, as the thread that met the refusal says - each left untouched, for the same call again."

changedOutput schema / properties / threads / items / properties / outcome / description

Previous value: -"done, whole; notDone, left as it was, reason saying why; possiblyDone, moved in part - messages saying which were - or asked with no answer back, so it may have moved: read it again with threads_get, or messages_get for a message, before acting on it again."New value: +"done, whole; notDone, left as it was, reason saying why; possiblyDone, moved in part - messages saying which were - or asked with no answer back, so it may have moved, which threads_get, or messages_get for a message, reads before it is acted on again."

Changed2 schema fields changedOct 30, 2026

changedOutput schema / properties / messages / items / properties / skipped / enum

Previous value: -[
-  "sent",
-  "drafts",
-  "deleted",
-  "queued"
-]New value: +[
+  "sent",
+  "drafts",
+  "deleted",
+  "queued",
+  "unsynced"
+]

changedOutput schema / properties / threads / items / properties / messages / items / properties / skipped / enum

Previous value: -[
-  "sent",
-  "drafts",
-  "deleted",
-  "queued"
-]New value: +[
+  "sent",
+  "drafts",
+  "deleted",
+  "queued",
+  "unsynced"
+]

Changed1 schema field changedOct 29, 2026

changedOutput schema / properties / notReached / description

Previous value: -"The ids the call did not reach - its time ran out, or the mailbox refused it whole, as the thread that met the refusal says - each left untouched: make the same call again with them."New value: +"The ids the call did not reach - its time ran out, its connection to the mailbox was lost, or the mailbox refused it whole, as the thread that met the refusal says - each left untouched: make the same call again with them."

Changed5 schema fields changedOct 29, 2026

addedInput schema / properties / ids

Added value: +{
+  "description": "2 to 100 threadIds - or with scope message message ids - in place of id, acted on in one call.",
+  "items": {
+    "description": "The provider's own identifier.",
+    "pattern": "^[A-Za-z0-9_=-]{1,512}$",
+    "type": "string"
+  },
+  "maxItems": 100,
+  "minItems": 2,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "mailbox",
-  "id"
-]New value: +[
+  "mailbox"
+]

addedOutput schema / properties / notReached

Added value: +{
+  "description": "The ids the call did not reach - its time ran out, or the mailbox refused it whole, as the thread that met the refusal says - each left untouched: make the same call again with them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / threads

Added value: +{
+  "description": "Each thread the call reached, with ids.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "labelIds": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "messages": {
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "done": {
+              "type": "boolean"
+            },
+            "id": {
+              "type": "string"
+            },
+            "restoredTo": {
+              "type": "string"
+            },
+            "skipped": {
+              "enum": [
+                "sent",
+                "drafts",
+                "deleted",
+                "queued"
+              ],
+              "type": "string"
+            }
+          },
+          "required": [
+            "id",
+            "done"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "outcome": {
+        "description": "done, whole; notDone, left as it was, reason saying why; possiblyDone, moved in part - messages saying which were - or asked with no answer back, so it may have moved: read it again with threads_get, or messages_get for a message, before acting on it again.",
+        "enum": [
+          "done",
+          "notDone",
+          "possiblyDone"
+        ],
+        "type": "string"
+      },
+      "reason": {
+        "description": "Why it is not done, as a refusal of the whole call names it.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "outcome"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / required

Removed value: -[
-  "id",
-  "labelIds"
-]

Changed1 schema field changedOct 25, 2026
- addedOutput schema / properties / messages / items / properties / restoredTo
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 25, 2026

addedOutput schema / properties / messages / items / properties / skipped

Added value: +{
+  "enum": [
+    "sent",
+    "drafts",
+    "deleted",
+    "queued"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedOct 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedOct 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing provider-specific restore semantics: Google-sign-in Gmail restores with every label, imap Gmail routes drafts/sent/other into different folders while preserving ids, and Outlook/imap returns messages to the folder they were moved from (latest move, within 30 days, folder still existing). It also discloses partial-failure behavior (done/notDone/possiblyDone/notReached) that the annotations do not cover. Nothing contradicts idempotentHint=true or destructiveHint=false.

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

Conciseness2/5

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

Purpose is front-loaded, but the remainder is one dense run-on paragraph with tangled clauses ('which threads_get - or messages_get for a message - reads to check') that must be re-read to parse. The content is relevant, yet it is not structured into scannable segments, hurting readability for an agent skimming the definition.

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 an output schema, the description covers everything an agent needs: per-provider restore destinations, the 30-day/folder-existence constraint, batch limits of 2-100, idempotency context, and the meaning of each partial-success status. No decision-relevant behavior is left unexplained.

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%, but the description adds meaning the schema lacks: it explains that 'ids' replaces 'id' and is batched under one call's time as 'one action', and that 'scope: message' narrows the operation to a single message whose id is accepted. It also explains that restored messages are reported with the folder as restoredTo, linking inputs to output fields.

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 first sentence names a specific verb and resource: 'Bring one thread, or one message of it, back out of the trash.' It also states the scope alternatives (whole thread vs single message) up front, so an agent can distinguish it from threads_trash, threads_archive, and threads_modify 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete operational guidance: 'possiblyDone ... which threads_get - or messages_get for a message - reads to check' and 'notReached ... for the same call again' tells the agent exactly how to follow up after a partial result. It does not explicitly compare itself to alternative restore paths (e.g. threads_modify removing the TRASH label), so the alternative-selection guidance is implicit rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Multi Mail tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.