Skip to main content
Glama
p-l-ta

mail-mcp

by p-l-ta

trash_email

Destructive

Move a specific email to the Trash folder using its RFC message-id, without permanently deleting it.

Instructions

Move a message to Deleted Messages (trash) by RFC message-id. Does not permanently delete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
message_idYesRFC message-id (with or without angle brackets)

Implementation Reference

  • The handler function for trash_email. It calls findMessageAndAct with the message_id and the AppleScript delete action, returning success or not-found error.
      async ({ message_id }) => {
        const result = await findMessageAndAct({
          messageId: message_id,
          action: ACTION,
        });
        if (result === MESSAGE_NOT_FOUND) {
          return {
            content: [{ type: "text", text: `No message found with id ${message_id}` }],
            isError: true,
          };
        }
        return { content: [{ type: "text", text: result }] };
      },
    );
  • Zod schema: expects a string `message_id` (RFC message-id).
    const schema = {
      message_id: z.string().describe("RFC message-id (with or without angle brackets)"),
    };
  • Registers 'trash_email' as an MCP tool with the server, including title, description, schema, and handler.
    export function register(server: McpServer): void {
      server.tool(
        "trash_email",
        "Move a message to Deleted Messages (trash) by RFC message-id. Does not permanently delete.",
        schema,
        { title: "Trash Email", readOnlyHint: false, destructiveHint: true },
        async ({ message_id }) => {
          const result = await findMessageAndAct({
            messageId: message_id,
            action: ACTION,
          });
          if (result === MESSAGE_NOT_FOUND) {
            return {
              content: [{ type: "text", text: `No message found with id ${message_id}` }],
              isError: true,
            };
          }
          return { content: [{ type: "text", text: result }] };
        },
      );
    }
  • src/server.ts:13-33 (registration)
    Top-level server registration: imports and invokes the trash tool's register function.
    import { register as registerTrash } from "./tools/trash.js";
    import { register as registerCreateMailbox } from "./tools/create_mailbox.js";
    import { register as registerBulkMarkRead } from "./tools/bulk_mark_read.js";
    import { register as registerGetUnsubscribeLink } from "./tools/get_unsubscribe_link.js";
    import { register as registerListSenders } from "./tools/list_senders.js";
    import { register as registerEmptyMailbox } from "./tools/empty_mailbox.js";
    
    const server = new McpServer({
      name: "mail-app-mcp",
      version: "1.0.0",
    });
    
    registerSearch(server);
    registerRead(server);
    registerAccounts(server);
    registerListRecent(server);
    registerSend(server);
    registerReply(server);
    registerFlags(server);
    registerMove(server);
    registerTrash(server);
  • AppleScript action snippet that deletes the found message and returns 'ok'.
    const ACTION = `
      delete foundMsg
      return "ok"
    `;
Behavior4/5

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

Discloses that the action moves to trash and does not permanently delete, which adds nuance beyond the destructiveHint annotation. With annotations already present, the description provides helpful clarification.

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 concise sentences with no redundancy. Every word adds value, making it highly efficient.

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?

Given the simplicity (1 param, no output schema) and presence of annotations, the description is complete enough. It explains the action and its non-destructive nature, though could mention expected return value or error cases.

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 coverage is 100% for the single parameter, so the description does not need to add much. The description mentions 'by RFC message-id' but the schema already describes the parameter format adequately.

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?

Clearly states it moves a message to Deleted Messages by RFC message-id and specifies it does not permanently delete. Distinguishes from permanent deletion but not explicitly from sibling move_email.

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?

No explicit guidance on when to use this tool versus alternatives like move_email or bulk_mark_read. Only states the action without contextual usage advice.

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/p-l-ta/mail-mcp'

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