Skip to main content
Glama
Knuckles-Team

vaultwarden-mcp

Delete attachment post admin

vaultwarden_delete_attachment_post_admin
Destructive

Deletes an attachment from a Vaultwarden server via the admin POST endpoint, requiring cipher and attachment IDs to remove the file.

Instructions

Delete an attachment (admin path, POST alias)

Input Schema

NameRequiredDescriptionDefault
formNo
paramsNo
cipher_idYes
json_bodyNo
attachment_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. Beyond that, the description adds nothing: it doesn't say whether deletion is irreversible, what admin privileges are required, or what happens to the parent cipher's attachment references.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single parenthetical sentence is front-loaded and free of filler, which is good. But the brevity crosses into under-specification for a destructive admin tool, so it's efficient without being sufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A destructive admin mutation with 5 undocumented parameters, no output schema, and four look-alike siblings needs far more than eight words. Essential information — admin auth requirement, irreversibility, path/alias selection — is absent.

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

Parameters1/5

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

Schema description coverage is 0% across five parameters, including opaque ones (form, params, json_body) that an agent cannot interpret without help. The description mentions no parameters at all, so it fully fails to compensate for the coverage gap on a destructive call.

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?

States a specific verb and resource ('Delete an attachment') and adds a routing qualifier ('admin path, POST alias') that distinguishes it from the plain sibling vaultwarden_delete_attachment. It doesn't explain what 'admin path' implies for the caller, but the operation itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There are four near-identical siblings (delete_attachment, delete_attachment_admin, delete_attachment_post, delete_attachment_post_admin), yet the description gives no rule for choosing this one over them. 'POST alias' hints at transport duplication but doesn't tell an agent when it matters or what prerequisites (admin credentials) apply.

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

Deploy Server

Other Tools