proton-mcp

Overview Schema Source Related Servers Discussions Admin

Propose a mail filter

propose_filter

Proposes a new Proton Mail filter or a full replacement for an existing one as a Sieve script, pending user confirmation in the browser extension before it takes effect.

Instructions

Proposes a new Proton Mail filter, or a new version of an existing one, as a complete Sieve script. By default the user confirms it in a window of the browser extension, which shows the whole script and, for a change, the difference to the current version. This call returns before they decide; list_filters shows the outcome. The script has to start with Proton's spam guard, exactly as existing filters from get_filters carry it, and may file into folders and labels and set or clear the read and star flags. Anything more only where the user allowed it, one action at a time: moving to Trash or Spam, discard, expire, reject, vacation and stop. list_filters says what is allowed now, and a refusal names what is not. redirect is not run by Proton's filters at all. To change a filter, pass its id as replaces and send the whole new script: it replaces the old one entirely, nothing is merged. A folder has to exist already; a name that matches none does nothing. Set applyToExisting to suggest that it also runs over the mail already there; in the window that is a box the user can untick. A new filter comes last in the order.

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": {
      "name": "<name>",
      "sieve": "<sieve>"
    },
    "name": "propose_filter"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The name Proton shows for the filter. For a change, the current name unless the user asked for a new one.
`sieve`	Yes	The complete Sieve script, starting with Proton's spam guard.
`replaces`	No	The id of the filter this one replaces, from list_filters. Left out for a new filter.
`applyToExisting`	No	Suggest applying it to the mail already there once it is saved. The user can untick it.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.1Nov 7, 2026

TDQS

A4.4/5.0

Behavior3/5

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

The annotations already declare non-read-only, non-idempotent, non-destructive, and closed-world, and the description adds substantial context beyond that: the browser-extension confirmation window, the fact that the call returns before the user decides, that replacements are whole-script with nothing merged, and that unsupported actions produce a named refusal. However, the confirmation window is a behavioral trait the agent must plan around, and the description could be clearer about whether the call fails outright when the user declines, so it stops short of full disclosure.

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 the core action and the async confirmation behavior, then organized by concern (allowed actions, changing a filter, folders, applyToExisting, ordering). It is dense and long, but nearly every clause carries operative information; a few sentences (the action permission list) could be tightened without losing meaning.

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?

There is no output schema, and the description compensates by explaining that the call returns before the user decides and that list_filters reveals the outcome. For a mutation tool with permission-gated behavior and whole-script replacement semantics, the description covers everything an agent needs to call it safely.

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 genuinely adds meaning: 'replaces' is described as replacing the old script entirely with nothing merged, 'applyToExisting' is framed as a suggestion the user can untick, and folder names must already exist or the rule does nothing. It does not add format or length constraints beyond the schema, so it sits just above baseline rather than at the top.

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 — 'Proposes a new Proton Mail filter, or a new version of an existing one, as a complete Sieve script' — which is immediately distinguishable from apply_filter, manage_filters, and get_filters. The create-vs-replace duality is spelled out in the same sentence.

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?

Explicitly names the sibling tools for each follow-up need: list_filters for the outcome and for currently allowed actions, get_filters for the canonical spam guard, and the 'pass its id as replaces' path for changes. It also states what is out of scope (redirect is never run) and what the agent must not attempt without permission.

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