Skip to main content
Glama
s-morgan-jeffries

apple-mail-mcp

delete_draft

DestructiveIdempotent

Delete an existing draft by moving it to the Trash, rendering it non-editable but recoverable.

Instructions

Delete (move to Trash) an existing draft.

Lifecycle endpoint for cancellation. Mail.app moves the message to the Deleted Messages mailbox; recovery is technically possible but Mail.app no longer treats trashed drafts as editable, so this is effectively a one-way discard. No elicitation (recoverable from Trash) and no rate limit (local operation).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
draft_idYesMail.app id of the draft.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

Beyond annotations (destructiveHint=true), the description adds that the operation is recoverable from Trash but effectively one-way, and mentions no rate limit. This provides useful behavioral context.

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 succinct with three sentences, each adding value: purpose, lifecycle context, and additional notes. No wasted words.

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 simple delete action with full annotations and schema coverage, the description covers purpose, behavior, and special constraints. It lacks only a mention of idempotency, but annotations cover that.

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?

The schema coverage is 100%, so the description does not need to add parameter details. The single parameter 'draft_id' is adequately described in the schema, and the description adds no further clarification.

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 clearly states 'Delete (move to Trash) an existing draft,' using a specific verb and resource. It distinguishes itself from sibling tools like delete_messages or delete_mailbox by specifying it targets drafts.

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?

The description provides context by calling it a 'Lifecycle endpoint for cancellation' and explaining the move to Trash. It implies when to use (to discard a draft) but does not explicitly contrast with alternatives like update_draft.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/s-morgan-jeffries/apple-mail-fast-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server