Skip to main content
Glama
Knuckles-Team

vaultwarden-mcp

Post rotatekey

vaultwarden_post_rotatekey

Rotate a Vaultwarden account key by re-encrypting the user key, private key, and all cipher, folder, and send keys to maintain access after key changes.

Instructions

Full account key rotation: re-encrypt user key, private key, and every cipher/folder/send key

Input Schema

NameRequiredDescriptionDefault
formNo
paramsNo
json_bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

C2.9/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description's enumeration of what is re-encrypted adds real substance about blast radius. However, it omits operationally critical behavior: whether the old master password is required, whether existing sessions/devices are invalidated, and whether the change is reversible — notable for an operation that rewrites every encrypted object.

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?

One compact sentence, front-loaded with the operation name followed by its scope. It is efficient, though it is arguably too terse for the stakes involved.

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 high-impact, irreversible-in-practice cryptographic operation with zero-documented parameters, no output schema, and only minimal annotations. The description gives the 'what' but not the credentials needed, the response, or the side effects on other sessions — an agent would be guessing at invocation.

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

Parameters2/5

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

Schema description coverage is 0% across three generically named parameters (form, params, json_body), and the description supplies no information about what belongs in them. Given a low-coverage schema, the description should compensate by naming the required key material, but it does not.

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 object ('Full account key rotation') and enumerates exactly what gets re-encrypted: user key, private key, and every cipher/folder/send key. This makes scope clear and hints at why it differs from the several '*rotate_api_key' / '*rotate_password' siblings, though it never names them explicitly.

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?

No guidance on when to invoke this versus vaultwarden_accounts_rotate_api_key, vaultwarden_organizations_rotate_api_key, or vaultwarden_maintenance_rotate_password, nor any stated prerequisites (e.g. supplying the current master password hash). The agent must infer everything about the trigger condition.

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