mcp-proton-mail

Overview Schema Source Related Servers Discussions Admin

Preview a Proton Sieve filter

preview_sieve_filter

Read-only

Preview a Proton Sieve filter for incoming mail and return its exact script without changing anything, so users can add the rule in Proton’s filter settings.

Instructions

Preview one Proton Sieve filter for new incoming mail and return its exact script; changes nothing.

Use it when the user wants Proton itself to file mail as it arrives. With Proton Mail Bridge, apply.available is false and create_sieve_filter refuses: show the script for the user to add in Proton's own filter settings (Add sieve filter), and do not call create_sieve_filter. For a rule this server applies to INBOX, use preview_add_rule; to move mail already received, preview_action.

conditions are 1 to 10 objects such as {"field": "from", "contains": "example.test"}; from and to match the address, subject the header, case-insensitively, and match="any" needs only one. Filters only file into folder and mark read only with mark_read=true; they never delete, discard, forward or reply, and never run on spam.

Returns the normalized filter, fileinto, the exact script, script_sha256, apply, a single-use token for create_sieve_filter (unusable on Bridge), expires_at and action_hash. A folder that is not an existing Folders/ name refuses.

Input Schema

Name	Required	Description	Default
`name`	Yes	A name for the filter, at most 100 characters.
`match`	No	all needs every condition to match; any needs one.	all
`folder`	Yes	An existing real Folders/ name, as search_mail reports it.
`mark_read`	No	Also mark matching mail read.
`conditions`	Yes	1 to 10 objects, each {"field": "from"\|"to"\|"subject"} plus exactly one of contains or is.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with concrete guarantees: filters 'never delete, discard, forward or reply, and never run on spam'. It goes further to disclose environment-dependent behavior (apply.available is false on Bridge, the token is unusable there, expires_at exists) and the failure mode for a non-existent folder, which annotations cannot convey.

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 'changes nothing' constraint, then usage, then semantics, then return values. Dense and mostly waste-free, though the paragraph on conditions/return values is long enough that an agent must scan a fair amount of prose to extract the key constraints.

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?

For a preview tool with a nested-ish condition array and a mutation-adjacent sibling, the description covers side effects, environment caveats, refusal conditions, and the returned fields. An output schema exists, yet the enumeration of returns is still useful for anticipating the single-use token and expiry, so nothing needed for correct invocation is missing.

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: conditions are 1-10 objects with from/to/subject mapping rules, matching is case-insensitive, match='any' needs only one hit, and folder must be an existing Folders/ name as search_mail reports it. Only the name character limit and mark_read default are left to the schema, so it is strong but not fully additive on every parameter.

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 ('Preview one Proton Sieve filter for new incoming mail') plus the exact artifact returned ('its exact script'), and immediately clarifies 'changes nothing'. It explicitly distinguishes itself from preview_add_rule, preview_action, and create_sieve_filter, so an agent can route correctly without opening schemas.

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?

Gives an explicit use case ('when the user wants Proton itself to file mail as it arrives'), two named alternatives with their selecting conditions (preview_add_rule for server-side INBOX rules, preview_action for already-received mail), and an explicit do-not-call instruction for create_sieve_filter under Proton Mail Bridge. When-to-use, when-not-to-use, and alternatives are all present.

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