mcp-proton-mail

Overview Schema Source Related Servers Discussions Admin

Move approved mail

move

Destructive

Relocates approved messages to Trash, Archive or a specified folder using an approved preview token, confirming the exact change first and returning log IDs for undo.

Instructions

Move the approved messages to Trash, Archive or a folder; only call after the user explicitly approved the preview.

Use it only with a move_to_trash, archive or move_to_folder token from preview_action that the user approved, or the continuation_token of that approval. target states the preview's target; the token pins the destination and is what the move uses, so any other target refuses before the form. Unless the operator turned it off, the user then confirms the exact change in the client's form. Moving to Trash deletes nothing, and this server never empties Trash.

Read-state changes use the preview's setting. If the approval includes creating a missing folder, it is created first (folder_creation reports it). limit caps the messages this call processes.

Returns target, log_ids (a list even for zero or one chunk), counts, run/continuation state and message IDs; verbose=true adds full rows. Pass each log_id to undo_action to move the messages back. Any untouched remainder gets a continuation, redeemed with the same target; a continuation reports a changed row in blocked_ids and leaves it untouched. An expired, used or unknown token refuses: preview again.

Input Schema

Name	Required	Description
`limit`	No	Messages to process in this call, 1 to 200. A value above the approved total refuses and keeps the token.
`token`	Yes	Single-use token from the preview the user approved, or the continuation_token of an earlier partial run of that approval.
`target`	Yes	The preview's target: "Trash", "Archive" or the exact Folders/ name. Any other value refuses without consuming the token.
`verbose`	No	true adds messages and replaces blocked_ids, missing_ids and mismatched_ids with full blocked, missing and mismatched rows.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is largely structured. The description adds genuine value beyond that: it discloses the client confirmation form, that Trash is never emptied, that read-state changes follow the preview's setting, that missing folders are created first, and full continuation/expiry behavior. That is substantial context on top of the annotations.

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 purpose and the approval prerequisite, and organized in short functional clauses. It is dense and somewhat long, and a few sentences restate what the schema already documents (limit, verbose rows), which keeps it from a 5.

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?

Covers everything an agent needs for a stateful, token-gated mutation: preconditions, confirmation, folder creation, continuation handling, blocked rows, token expiry, and how to reverse with undo_action. Even with an output schema present, the return-value summary is appropriately brief.

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 real meaning the schema does not: target merely echoes the preview while the token pins the destination, so a mismatched target refuses before the confirmation form. It also explains that limit caps the messages this call processes and that a continuation is redeemed with the same target.

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?

States a specific verb and resource ('Move the approved messages to Trash, Archive or a folder') and immediately distinguishes itself from siblings by requiring an approved preview token from preview_action. An agent can tell it apart from preview_action, apply_rules and undo_action without opening any 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?

Explicit gating: 'only call after the user explicitly approved the preview', and it names the alternative ('preview again') when the token is expired, used or unknown. It also names undo_action as the reverse path, so both directions are routed.

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