Skip to main content
Glama
proton-mcp

proton-mcp

by RndmJoker

Delete saved attachments

delete_saved_attachments
DestructiveIdempotent

Deletes attachment files saved by this server, either all of them or only the paths you specify, while leaving files it did not save untouched. Use it to clear downloads before the automatic one-hour cleanup.

Instructions

Deletes attachment files this server saved with save_attachment: all of them, or the paths given. A file this server did not save is never touched, and neither is one that was changed or replaced since it was saved. Saved files are deleted on their own after 1 hour(s) and when the server stops; this is for sooner.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "delete_saved_attachments"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathsNoOptional: the paths save_attachment reported. Without them, every saved file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.13

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare destructive and idempotent, but the description adds substantive behavior the annotations cannot convey: the tool only ever deletes files this server itself saved, skips files changed or replaced since saving, and exists as an early-expiry alternative to the 1-hour automatic cleanup. That is exactly the risk context an agent needs before invoking a destructive tool.

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?

Three front-loaded sentences, each carrying distinct information: scope, safety exclusion, and lifecycle rationale. Minor roughness in '1 hour(s)' and the elliptical final clause 'this is for sooner' keeps it from being flawless.

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 one-parameter destructive tool with full schema coverage and no output schema, the description covers scope, safety boundaries, and the timing rationale that motivates use. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and the single path parameter is already documented as optional with the same all-files default. The description restates that behavior ('all of them, or the paths given') without adding format or sourcing detail, so the schema continues to carry the load.

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 (Deletes) and a precisely scoped resource (attachment files this server saved with save_attachment), plus the two modes (all, or given paths). The scope qualifier distinguishes it from a general file-deletion tool and ties it directly to the save_attachment sibling.

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?

Gives a clear operative context: saved files already expire after 1 hour and on server stop, so this tool is for deleting sooner. It does not explicitly state when not to use it, but the scoping rule ('a file this server did not save is never touched') effectively excludes the main wrong-use case.

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