Skip to main content
Glama
BuddyKang

FudanMailBox MCP

by BuddyKang

delete_message

Move email messages to Trash by default; permanently delete them only when permanent and confirm are set to true. Specify a UID and optional folder to remove mail from an IMAP account.

Instructions

Move to Trash by default. Permanent deletion requires permanent=true and confirm=true.

Input Schema

NameRequiredDescriptionDefault
uidYes
folderNoINBOX
confirmNo
permanentNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/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 well: it discloses the safe default (move to Trash) and that permanent deletion is gated behind both permanent=true and confirm=true, a genuine safety-relevant behavior. It omits auth/permission requirements and confirmation of irreversibility.

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?

Two terse sentences, zero waste, with the default behavior front-loaded ahead of the opt-in destructive path. Exactly the right size for the information conveyed.

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

Completeness3/5

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

An output schema exists so return values need not be described. However, for a destructive tool with no annotations, the description should say more about irreversibility, the folder parameter's role, and permission requirements; it covers the mode switch but not the surrounding context.

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 0% across 4 parameters, so the description must compensate. It meaningfully explains the interaction between permanent and confirm (both required for hard delete), but leaves uid and folder undocumented, covering only half the parameters.

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?

The name plus description make clear this deletes a specific message, and the description adds the crucial distinction between Trash and permanent removal. It does not explicitly differentiate from siblings like archive_message, move_message, or delete_folder, but the verb+resource is unambiguous.

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

Usage Guidelines2/5

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

The description explains the two deletion modes but gives no guidance on when to delete versus archive_message or move_message, and no prerequisites or warnings about choosing permanent deletion. Usage context is left entirely to inference.

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