proton-mcp

Overview Schema Source Related Servers Discussions Admin

Move mail filters in their order

reorder_filters

Move Proton Mail filters to new positions in the order they run, controlling which filter's folder assignment wins for incoming messages.

Instructions

Moves one or several Proton Mail filters to other places in the order Proton runs them. Each move names a filter by id and the position it ends up at, counted from 1 as list_filters shows the order; moves are made one after the other. Every filter runs on each incoming message, and a matching one does not stop the rest, only stop and discard do; when several file a message into folders, the last one wins, labels add up. So a move can change where mail ends up. By default the user confirms the new order in a window of the browser extension, and this call returns before they decide.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "moves": "<moves>"
    },
    "name": "reorder_filters"
  }
}

Input Schema

Name	Required	Description	Default
`moves`	Yes	One or several moves, made one after the other.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.1Nov 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations cover safety hints, but the description adds traits they cannot express: moves are applied sequentially, a move can change where mail is filed (folders use last-wins, labels accumulate, only stop/discard halt processing), and by default the user must confirm the new order in a browser extension window while the call returns before that decision. That last point is critical for an agent's control flow and is invisible in the structured fields.

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?

It is front-loaded with the action, then consequence, then confirmation behavior. Some phrasing repeats the schema verbatim ('counted from 1 as list_filters shows the order' appears in both), and the filter-execution aside is dense, but every sentence contributes decision-relevant information.

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 single-parameter mutation tool with no output schema, the description covers preconditions, ordering semantics, side effects on mail routing, and the deferred-confirmation return behavior. The only gap is that it does not state what the immediate return value contains (e.g., a pending-confirmation indicator), which an agent awaiting completion would benefit from.

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 goes further by explaining that positions are 1-based relative to list_filters output and that multiple moves are applied one after another — implying later moves are interpreted against the progressively updated order. That sequential semantics is genuinely useful and not captured by the schema's per-item descriptions.

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 opens with a specific verb and resource: 'Moves one or several Proton Mail filters to other places in the order Proton runs them.' It also implicitly distinguishes itself from list_filters (the read path for getting the current order) and manage_filters (the general lifecycle tool), so an agent can select it without inspecting schemas.

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 explains the required workflow precondition clearly: each move names a filter id and a target position 'counted from 1 as list_filters shows the order,' which tells the agent to read the order first. It does not explicitly state when to prefer this over manage_filters or explain batching constraints (max 50 moves, made sequentially), but the usage context is unambiguous.

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