Skip to main content
Glama

Manage Trash

manage_trash

Preview and move emails to Trash, or attempt to empty Apple Mail's trash with dry-run safety checks.

Instructions

Manage trash operations - delete emails or empty trash.

When dry_run=True (default) and action is "move_to_trash", previews what would be deleted without acting. Set dry_run=False to actually move to trash.

Mail's AppleScript interface has no command that erases a message: delete means "move to Trash", and on a message that already sits in Trash it does nothing. "delete_permanent" and "empty_trash" therefore usually remove nothing at all. Both report the real before/after mailbox count instead of the number of delete calls, and say so when nothing was removed; emptying the trash for good has to happen in Mail itself.

Input Schema

NameRequiredDescriptionDefault
actionYesAction to perform: "move_to_trash", "delete_permanent", "empty_trash"
senderNoOptional sender to filter emails (not used for empty_trash)
accountYesAccount name (e.g., "Gmail", "Work")
dry_runNoIf True (default), preview what would be affected without acting
mailboxNoSource mailbox (default: "INBOX", not used for empty_trash or delete_permanent)INBOX
max_deletesNoMaximum number of emails to delete (safety limit, default: 5)
apply_to_allNoMust be True to allow operations without subject_keyword or sender filter
confirm_emptyNoMust be True to execute "empty_trash" action (safety confirmation)
older_than_daysNoOptional age filter - only affect emails older than N days
subject_keywordNoOptional keyword to filter emails (not used for empty_trash)
subject_keywordsNoOptional list of subject keywords; matches any keyword

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed27 schema fields changedv3.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / account / description
      Added value: +"Account name (e.g., \"Gmail\", \"Work\")"
    • removedInput schema / properties / account / title
      Removed value: -"Account"
    • addedInput schema / properties / action / description
      Added value: +"Action to perform: \"move_to_trash\", \"delete_permanent\", \"empty_trash\""
    • removedInput schema / properties / action / title
      Removed value: -"Action"
    • addedInput schema / properties / apply_to_all / description
      Added value: +"Must be True to allow operations without subject_keyword or sender filter"
    • removedInput schema / properties / apply_to_all / title
      Removed value: -"Apply To All"
    • addedInput schema / properties / confirm_empty / description
      Added value: +"Must be True to execute \"empty_trash\" action (safety confirmation)"
    • removedInput schema / properties / confirm_empty / title
      Removed value: -"Confirm Empty"
    • addedInput schema / properties / dry_run / description
      Added value: +"If True (default), preview what would be affected without acting"
    • removedInput schema / properties / dry_run / title
      Removed value: -"Dry Run"
    • addedInput schema / properties / mailbox / description
      Added value: +"Source mailbox (default: \"INBOX\", not used for empty_trash or delete_permanent)"
    • removedInput schema / properties / mailbox / title
      Removed value: -"Mailbox"
    • addedInput schema / properties / max_deletes / description
      Added value: +"Maximum number of emails to delete (safety limit, default: 5)"
    • removedInput schema / properties / max_deletes / title
      Removed value: -"Max Deletes"
    • addedInput schema / properties / older_than_days / description
      Added value: +"Optional age filter - only affect emails older than N days"
    • removedInput schema / properties / older_than_days / title
      Removed value: -"Older Than Days"
    • addedInput schema / properties / sender / description
      Added value: +"Optional sender to filter emails (not used for empty_trash)"
    • removedInput schema / properties / sender / title
      Removed value: -"Sender"
    • addedInput schema / properties / subject_keyword / description
      Added value: +"Optional keyword to filter emails (not used for empty_trash)"
    • removedInput schema / properties / subject_keyword / title
      Removed value: -"Subject Keyword"
    • addedInput schema / properties / subject_keywords / description
      Added value: +"Optional list of subject keywords; matches any keyword"
    • removedInput schema / properties / subject_keywords / title
      Removed value: -"Subject Keywords"
    • removedInput schema / title
      Removed value: -"manage_trashArguments"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"manage_trashOutput"
    • addedOutput schema / x-fastmcp-wrap-result
      Added value: +true
  2. First observedv3.1.0

TDQS

A3.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so exceptionally: it discloses that Mail's AppleScript 'delete' only moves to Trash, that delete_permanent and empty_trash usually remove nothing, that results report real before/after mailbox counts rather than call counts, and that permanent emptying must be done in Mail itself. These are non-obvious, high-value behavioral traits an agent could not infer elsewhere.

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?

The lead sentence is front-loaded and the critical limitation follows immediately. It is somewhat verbose with backticked command names and quotes, but every sentence conveys a distinct, useful fact, so waste is minimal.

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 complex 11-parameter destructive tool, the description covers the essential behavioral caveats, and the existence of an output schema removes the need to explain return values. The only gap is the lack of explicit routing against sibling tools, but otherwise it is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 11 parameters, establishing a baseline of 3. The description adds useful context by reinforcing the dry_run default and the semantics of the action values, but does not meaningfully extend parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Manage trash operations - delete emails or empty trash.' An agent can tell this concerns trash deletion, but the description does not distinguish it from the sibling move_email, which also relocates messages, so sibling differentiation is incomplete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It gives clear operational context for the dry_run flag (default preview, set False to act) and explains what each action does, but it never states when to choose this tool over move_email or delete_permanent-style alternatives, nor are any exclusions drawn. Usage is implied rather than explicitly routed.

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