Skip to main content
Glama
Sign In

Multi Mail

by co.lumman
OverviewDiscussionsAdmin

Move a thread to the trash

threads_trash
DestructiveIdempotent

Move one thread, or one message of it, to the trash - Gmail's bin, an Outlook mailbox's Deleted Items, the trash folder of a mailbox whose provider is imap - where it stays until threads_untrash brings it back or the provider's own retention ends it. A Gmail mailbox whose provider is imap keeps every label but the inbox on it and each message its id; in any other mailbox whose provider is imap each moved message takes a new id, which the answer names. 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

NameRequiredDescriptionDefault
idNoThe threadId a search or a read answered, or with scope message the message's id.
idsNo2 to 100 threadIds - or with scope message message ids - in place of id, acted on in one call.
scopeNothread, the default, acts on the whole thread; message acts on that one message alone.
mailboxYesThe mailbox's name or its email address.

Output Schema

NameRequiredDescriptionDefault
idNo
threadsNoEach thread the call reached, with ids.
labelIdsNo
messagesNo
newestOnlyNoThe 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.
notReachedNoThe 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.

  1. Changed2 schema fields changed
    • 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"
+}
  2. Changed2 schema fields changed
    • 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."
  3. Changed2 schema fields changed
    • 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"
+]
  4. Changed1 schema field changed
    • 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."
  5. Changed5 schema fields changed
    • 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"
-]
  6. Changed1 schema field changed
    • addedOutput schema / properties / messages / items / properties / skipped
      Added value: +{
+  "enum": [
+    "sent",
+    "drafts",
+    "deleted",
+    "queued"
+  ],
+  "type": "string"
+}
  7. Changed2 schema fields changed
    • 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"
  8. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructive and idempotent annotations, it discloses reversibility, provider-controlled retention, provider-specific label and message-ID effects, partial completion, timeouts, connection failures, and which items remain untouched. These details substantially clarify the side effects and failure behavior of the mutation.

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?

The purpose is front-loaded and the content is relevant, but the final sentence is an excessive run-on covering batching, statuses, verification, failure causes, and retries. Dense phrasing and repeated dashes make otherwise valuable instructions difficult to parse; shorter sentences or bullets would be much clearer.

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 provider-dependent, batch-capable destructive operation, the description supplies unusually complete context about scope, persistence, ID changes, partial failures, verification, and safe retries. The input and output schemas cover the remaining structural details.

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%, and the description repeats some of it, including the 2-to-100 batch range and message scope. It nevertheless adds useful meaning about batch action counting, per-item outcomes, newly assigned IDs, and how scope affects the appropriate verification tool.

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 opening clearly states the verb, resource, and scope: moving either a whole thread or one message to the trash. It also maps trash to provider-specific folders and distinguishes the operation from threads_untrash.

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 concrete operational guidance for single versus batch calls using id or ids, names threads_untrash for reversal, and directs the agent to threads_get or messages_get after an ambiguous possiblyDone result. It also explains that notReached items can be retried with the same call.

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

All Multi Mail toolsInspect
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.

Resources