protonmail-mcp-server

Overview Schema Source Related Servers Discussions Admin

Radera mejl

delete_email

Destructive

Permanently deletes a ProtonMail email when permanent is true; otherwise moves it to Trash. Requires UID and mailbox; supports up to 100 UIDs.

Instructions

Ta bort ett e-post genom att flytta det till papperskorgen (Trash).

Standard (permanent=False): mejlet flyttas till Trash, precis som "ta bort" i Protons egna appar, och kan återställas därifrån. Fungerar från INBOX, Archive, Sent, Spam, Drafts och Folders/…. Avvisas med fel om mejlet redan ligger i Trash, om mailbox är All Mail (Bridge nekar), och om mailbox är en etikett (Labels/…) eller Starred, eftersom mejlet då redan kan ligga i Trash och Bridge i så fall raderar det permanent — ange mappen där mejlet ligger i stället.

Ett Proton-mejl kan synas i flera mappar: ett mejl till sig själv är ETT mejl i både INBOX och Sent, och Bridges vyer släpar 20–40 s efter en flytt. Ligger mejlet redan i Trash (t.ex. Sent-kopian strax efter att INBOX-kopian tagits bort) görs ingenting med det, eftersom Bridge då skulle radera det permanent; det räknas som ok och svaret förklarar det i "note". Samma mejl känns igen på Protons mejl-id; går det inte att avgöra (flera likadana mejl i Trash) flyttas mejlet inte och det blir ett fel.

permanent=True: raderar mejlet permanent. Går bara när mailbox är Trash (eller Drafts för utkast) och kan inte ångras. Har mejlet kvar en etikett tar Bridge bara bort det ur Trash/Drafts. Bara det angivna mejlet påverkas. Bridge kan neka raderingen ("Message does not exist", Code=2501) men ändå genomföra den när Bridge synkar med Proton; då väntar verktyget upp till 45 s på att mejlen försvinner. Bridge avbryter då hela omgången före raderingen, så ett mejl räknas som raderat först när det inte heller finns i All Mail; mejl som blivit kvar där utan mapp raderas via Trash. Går det inte att avgöra hamnar mejlet i failed med en förklaring.

Args: uid: UID:t som sträng, eller en lista med upp till 100 UID:n ur samma mailbox mailbox: Mappen som UID:t kom från (obligatorisk). UID:n gäller per mapp: samma nummer i en annan mapp är ett annat mejl. Använd fältet mailbox från svaret av list_emails, search_emails eller get_email. permanent: Radera permanent i stället för att flytta till Trash (standard: False)

Returns: True när mejlet är flyttat eller raderat. Annars kastas ett fel med förklaring, t.ex. om UID:t inte finns i mailbox. Låg mejlet redan i Trash blir svaret {"ok": [UID], "failed": [], "note": "... ligger redan i papperskorgen ..."} i stället för True. Med en lista med UID:n blir svaret {"ok": [UID, ...], "failed": [{"uid": ..., "error": ...}]}: ett resultat per UID, i ett enda IMAP-kommando. UID:n som inte finns eller som Bridge nekar hamnar i failed medan de andra genomförs. UID:n vars mejl redan låg i Trash räknas som ok och nämns i "note". Ett ogiltigt UID (inte heltal) eller fler än 100 avvisar hela anropet innan något ändras.

Input Schema

Name	Required	Description
`uid`	Yes	Mejlets UID i mailbox, eller en lista med upp till 100 UID:n ur samma mailbox. Med en lista blir svaret {"ok": [UID, ...], "failed": [{"uid": ..., "error": ...}]}.
`mailbox`	Yes
`permanent`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.4.0Oct 21, 2026

removedInput schema / properties / mailbox / default
```
Removed value: -"INBOX"
```
addedInput schema / properties / mailbox / maxLength
```
Added value: +255
```
addedInput schema / properties / mailbox / minLength
```
Added value: +1
```

addedInput schema / properties / permanent

Added value: +{
+  "default": false,
+  "title": "Permanent",
+  "type": "boolean"
+}

addedInput schema / properties / uid / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "maxItems": 100,
+    "minItems": 1,
+    "type": "array"
+  }
+]

addedInput schema / properties / uid / description

Added value: +"Mejlets UID i mailbox, eller en lista med upp till 100 UID:n ur samma mailbox. Med en lista blir svaret {\"ok\": [UID, ...], \"failed\": [{\"uid\": ..., \"error\": ...}]}."

removedInput schema / properties / uid / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "uid"
-]New value: +[
+  "uid",
+  "mailbox"
+]

addedOutput schema / properties / result / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  }
+]

removedOutput schema / properties / result / type
```
Removed value: -"boolean"
```

First observedv0.1.0Jul 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond destructiveHint=true, the description discloses irreversibility of permanent=True, mailbox-specific restrictions, 20–40s view lag, the up-to-45s retry wait, ambiguous-UID failure handling, and the exact batch contract (per-UID ok/failed, one IMAP command, whole call rejected on invalid input). This is far richer than what the annotations convey and does not contradict them.

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 primary behavior and organized under clear headings (Standard, permanent=True, Args, Returns), so it is navigable despite its length. It loses a point for repetition, restating the already-in-Trash scenario three separate times and reproducing return-value detail that duplicates the existing output schema.

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 destructive, batch-capable IMAP tool with two modes, every decision-relevant fact is present: preconditions per mailbox, irreversibility, timing expectations, ambiguity handling, and per-UID batch results. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at only 33% (mailbox and permanent have no schema description), the Args section compensates fully: it explains that UIDs are per-mailbox, that mailbox is required and should come from the mailbox field of list_emails/search_emails/get_email, and that uid accepts one string or up to 100 UIDs from the same mailbox.

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?

The first sentence states a specific verb+resource+mechanism: 'Ta bort ett e-post genom att flytta det till papperskorgen (Trash)', and it clearly separates the two operating modes (default move vs. permanent=True). It does not, however, name or contrast itself against the sibling move_email, which is the nearest alternative an agent might confuse it with.

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?

The description gives explicit when-to-use and when-NOT-to-use rules: works from INBOX, Archive, Sent, Spam, Drafts, Folders/…; rejected for All Mail, Labels/…, Starred, and for mail already in Trash, with the reason (Bridge would permanently delete) and the corrective action ('ange mappen där mejlet ligger i stället'). Alternative routing is spelled out rather than inferred.

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