Skip to main content
Glama

Mailbox MCP

by com.mailbox-mcp.mcp
OverviewDiscussionsAdmin

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. 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, so move_email({to:"Archive"}) can file messages somewhere the mail client does not treat as the archive, 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, search_emails or select_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. Changed1 schema field changed
    • changedInput schema / properties / uids / description
      Previous value: -"The 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."New value: +"The UIDs to act on, from list_emails, search_emails or select_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."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare a mutating, non-idempotent, open-world operation, and the description adds substantial context beyond them: a folder may be created and subscribed if none exists, the caller must tell the user a new folder will appear, messages must share one source folder, flags and original dates are preserved, and the reply reports the folder used plus each message's new UID. Nothing contradicts the destructiveHint/readOnlyHint profile.

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

Conciseness4/5

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

Front-loaded with the core action and its key caveat, and nearly every sentence carries decision-relevant information. It runs long for a two-parameter tool, with some client-specific color (Gmail/Outlook/Roundcube) that could be tightened, but it is not padded.

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 the return payload (folder actually used and each message's new UID), the side effect of folder creation, the refusal case, and preservation guarantees. An agent has everything needed to call it correctly and to report the outcome to the user.

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, but the description adds operational meaning: all UIDs must come from the SAME source folder, batching in one call is preferred over per-message calls, and the returned new UIDs are what you need to reverse the move. That goes beyond the schema's field-level text.

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 names a specific verb and resource and pins down the exact semantics: 'Archive messages - file them where this mailbox's own Archive button files them, out of the inbox but not deleted.' It explicitly distinguishes the operation from move_email({to:"Archive"}), so an agent can tell the two apart without opening either schema.

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-not guidance ('REFUSES messages that are already in the archive... use move_email if they want them somewhere else') and names the alternative tool with the condition that selects it. It also warns against the naive path of moving to a folder literally named 'Archive'.

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

All Mailbox MCP 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