vaultwarden_get_cipher_detailsRetrieves one vault cipher with full details, including collection IDs, so you can inspect its complete configuration and access scope.
Get one cipher with full details incl. collection ids
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | ||
| params | No | ||
| cipher_id | Yes | ||
| json_body | No |
Changes observed during successful MCP inspections.
v0.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful fact beyond that — the response includes collection ids — but says nothing about error behavior for a missing cipher_id, permissions required, or whether deleted/archived ciphers are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the key scope detail front-loaded and no filler. Its brevity is efficient, though it shades into under-specification given the gaps elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In a namespace of 200+ mostly overlapping cipher tools, a single clause is thin: no parameter guidance for an undocumented 4-parameter schema, no output schema to fall back on, and no differentiation from the sibling get tools. Annotations cover safety, but not the disambiguation an agent actually needs here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and cipher_id is declared as an untyped empty object, yet the description never mentions it or the three sibling parameters form, params, and json_body. With four undocumented parameters the description would need to compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (get) plus resource (one cipher) with a scope hint ('full details incl. collection ids') that separates it from the list tool get_ciphers. It does not, however, distinguish itself from the near-identical siblings vaultwarden_get_cipher and vaultwarden_ciphers_get_item, leaving ambiguity about which retrieval variant to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this over vaultwarden_get_cipher, vaultwarden_ciphers_get_item, or vaultwarden_get_ciphers, and no prerequisites such as authentication or ownership of the cipher. The agent must infer selection purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.