Skip to main content
Glama

Archive emails

archive_email
Destructive

Archive messages - file them where this mailbox's own Archive button files them, out of the inbox but not deleted. USE THIS RATHER THAN move_email FOR ARCHIVING: the archive is a ROLE the mail server assigns to a folder, not a name, so it is "Archive" on Microsoft 365, it is All Mail on Gmail (where archiving means the message simply stops being in the inbox and keeps no other folder), and on many IMAP hosts it does not exist until something makes it. A folder merely NAMED "Archive" is not necessarily the one the mail client archives into, which is why move_email({to:"Archive"}) is the wrong tool here and can be refused on a mailbox whose folder list plainly shows one. IF THIS MAILBOX HAS NO ARCHIVE FOLDER, ONE IS CREATED, and subscribed so it shows up in Outlook and Roundcube; the reply says so - tell the user, because a new folder will appear in their mail client. REFUSES messages that are already in the archive, because there is nothing to do; use move_email if they want them somewhere else. All the messages must be in the SAME source folder. Flags and the original dates are preserved, so an archived backlog keeps the dates it arrived on and does not come back unread. Pass every UID in one call rather than calling it once per message. The reply names the folder actually used and the new uid of each message there, which is what you need to put any of them back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidsYesThe UIDs to act on, from list_emails or search_emails. Pass EVERY message you want changed in ONE call - this tool acts on the whole set in a single operation, and doing it that way costs the user one call instead of one per message. Up to 500 at a time. A single message is simply a one-element array.
mailboxNoThe folder the messages are in now. Defaults to INBOX.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior1/5

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

Annotations declare destructiveHint:true, but the description explicitly says messages go 'out of the inbox but not deleted,' preserves flags and dates, and returns new UIDs so messages can be put back. This directly contradicts the destructive hint, so an agent cannot reliably know whether this operation is safe or destructive.

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 long but every sentence earns its place, covering core behavior, the move_email distinction, folder creation, refusal behavior, preservation guarantees, batching, and response contents. It is front-loaded with the most important operational facts and has no 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 still explains what the reply contains (folder actually used and new UIDs), side effects (folder creation and subscription), refusal cases, and cross-parameter constraints. An agent can invoke this tool correctly and communicate the outcome, including the possibility of a newly appearing folder.

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?

The input schema already documents both parameters in detail with high coverage, so the baseline is 3. The description adds a meaningful constraint beyond the schema: all messages must come from the same source folder, and it reinforces that every UID should be passed in a single call.

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 opens with a specific verb and resource ('Archive messages') and explains exactly what archiving means: filing messages where the mailbox's own Archive button files them, out of the inbox but not deleted. It also clearly distinguishes itself from move_email by explaining that the archive is a server-assigned role, not a folder name.

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?

The description explicitly says 'USE THIS RATHER THAN move_email FOR ARCHIVING' and explains why move_email with a folder named 'Archive' can be wrong. It also states when to use move_email instead, and gives batch and same-source-folder requirements, leaving no ambiguity about when this tool should be selected.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources