Skip to main content
Glama
Knuckles-Team

vaultwarden-mcp

Vaultwarden Ciphers

vaultwarden_ciphers

Manage vault ciphers via MCP: list, read, create, edit, or soft-delete items; recover deleted entries from trash.

Instructions

Read and write vault items (ciphers).

The decrypted actions (list_items, get_item, create_item, edit_item) return or accept plaintext item contents because the caller explicitly asked for them — never log, echo, or otherwise surface that content elsewhere. move_to_trash soft-deletes items by id (recoverable). Every other ciphers API route is reachable by its route name via call_operation.

CONCEPT:VW-ECO.mcp.cipher-operations

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesOne of 'list_items', 'get_item', 'create_item', 'edit_item', 'move_to_trash', or any raw ciphers-domain Route.name. Call with action='list_actions' to list every available operation.
params_jsonNoJSON object of parameters for the action.{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: decrypted actions return/accept plaintext (a real security constraint), and move_to_trash is a recoverable soft-delete. It omits auth requirements and rate limits, but the plaintext and soft-delete disclosures are genuine beyond-schema value.

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?

The core purpose is front-loaded in the first sentence, followed by tightly scoped operational notes; little is wasted. The trailing CONCEPT tag is non-functional noise but doesn't materially bloat the definition.

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

Completeness4/5

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

An output schema exists, so return values need not be explained, and the description covers the key actions plus the call_operation fallback and a list_actions discovery path. For a multi-action dispatcher with no annotations, this is nearly complete, missing only auth/scope prerequisites.

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 description coverage is 100%, so the schema already documents 'action' and 'params_json', establishing a baseline of 3. The description names the valid actions and points to list_actions, but adds no syntax or format detail for the params_json payload beyond what the schema states.

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 description opens with a specific verb+resource pair, 'Read and write vault items (ciphers),' and enumerates the primary actions (list_items, get_item, create_item, edit_item, move_to_trash). An agent can see it operates on vault items, though it never explicitly contrasts itself with siblings like vaultwarden_accounts or vaultwarden_folders.

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

Usage Guidelines3/5

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

It explains the privileged decrypted actions and notes that other ciphers routes are reachable by route name via call_operation, which implies a usage pattern. However, it offers no explicit when-to-use-this-vs-sibling guidance or prerequisites, leaving selection between the vaultwarden_* tools largely to inference.

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