Skip to main content
Glama
Sign In

Multi Mail

by co.lumman
OverviewDiscussionsAdmin

Archive a thread

threads_archive
DestructiveIdempotent

Take one thread, or one message of it, out of the inbox: a Gmail mailbox, whatever its provider, takes its inbox label off, and an Outlook one moves it into its archive folder. It stays in the mailbox and in search. Any other mailbox whose provider is imap moves its inbox messages into its archive folder, made as Archive where it has none, each under a new id 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. Changed2 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"The threadId a search or a read answered."New value: +"The threadId a search or a read answered, or with scope message the message's id."
    • addedInput schema / properties / scope
      Added value: +{
+  "description": "thread, the default, acts on the whole thread; message acts on that one message alone.",
+  "enum": [
+    "thread",
+    "message"
+  ],
+  "type": "string"
+}
  7. Changed1 schema field changed
    • addedOutput schema / properties / messages / items / properties / skipped
      Added value: +{
+  "enum": [
+    "sent",
+    "drafts",
+    "deleted",
+    "queued"
+  ],
+  "type": "string"
+}
  8. 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"
  9. First observed

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 (destructiveHint, idempotentHint): it discloses that the item stays in the mailbox and in search, that an Archive folder may be created with new ids returned in the answer, and that batch calls can end partially with done / notDone / possiblyDone / notReached outcomes, including timeout and connection-loss causes. That is substantive operational context an agent could not get from the annotations alone. Note the mild tension with destructiveHint=true since the description stresses the mail remains searchable, but this is a nuance rather than a contradiction.

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

Conciseness3/5

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

The purpose is front-loaded in the opening clause, which is good, but the rest is one sprawling run-on sentence with dense clauses and informal phrasing ('under one call's time', 'asked with no answer back') that makes the batch and outcome semantics harder to parse than necessary. No filler sentences, but readability suffers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with batch semantics and partial-failure modes, the description covers the essentials: what changes per provider, what persists, what the outcome buckets mean, and the retry path. An output schema exists, so the extra detail on result buckets is bonus rather than obligation; only the relationship to threads_modify and the exact id format are left unaddressed.

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 the baseline is 3, and the description adds real meaning on top: ids is a mutually exclusive alternative to id, is capped at 2-100, and is processed as one action within a single call's time; scope=message targets one message rather than the whole thread. It stops short of documenting the id pattern/format constraints, which the schema already covers.

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 concrete verb and resource (take a thread or message out of the inbox, i.e. archive) and then spells out the provider-specific effect: Gmail loses its inbox label, Outlook moves to archive folder, IMAP moves inbox messages to an Archive folder created if absent. It also implicitly separates itself from threads_get/messages_get by naming them as the read tools used to verify possiblyDone results.

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 clear conditions for the two input shapes: a single id for one thread or message, or ids for 2-100 at once counted as one action. It also explains what to do on partial failure (re-run the notReached entries). It never explicitly contrasts with threads_modify (which can also remove the inbox label) or threads_trash, so the sibling choice is left partly to inference.

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