@aiwerk/mcp-server-vault
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DRY_RUN | No | Set 1 to log write operations without executing them | 0 |
| READ_ONLY | No | Set 1 to block all write operations (Send creation and save) | 0 |
| VAULT_API_BASE | Yes | Base URL of your Bitwarden/Vaultwarden instance (no trailing slash) | |
| VAULT_CLIENT_ID | Yes | Personal API key client_id (e.g. user.abc-def-1234) | |
| VAULT_CLIENT_SECRET | Yes | Personal API key client_secret | |
| VAULT_API_TIMEOUT_MS | No | HTTP timeout in milliseconds | 15000 |
| VAULT_MASTER_PASSWORD | Yes | Vault master password (used for E2E decryption key derivation) | |
| VAULT_EXPOSED_COLLECTION | No | Name of the collection visible to agents | mcp-exposed |
| VAULT_AGENT_CREATED_COLLECTION | No | Name of the collection for agent-created secrets | mcp-agent-created |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_vault_itemsA | List vault items from the mcp-exposed and mcp-agent-created collections. Returns metadata only. Secret values and note contents are NEVER included (has_notes says whether notes exist). Use reveal_secret_via_send to obtain the actual value through a secure Bitwarden Send URL. |
| get_vault_metadataA | Get full metadata for a named vault item. Returns name, type, username (for login items), URIs, custom fields, scope, expiry, and whether the item has notes. Password, TOTP seed, api-key values and note contents are NEVER returned. Use reveal_secret_via_send (field "notes" for the notes) or get_totp_code instead. |
| reveal_secret_via_sendA | Reveal a vault secret through a Bitwarden Send, an E2E-encrypted one-time URL. Creates a temporary Send with a configurable TTL and max-views limit. The secret value is encrypted client-side; only the URL fragment (never sent to server) can decrypt it. Blocked when READ_ONLY=1. Logs to DRY_RUN without creating a real Send when DRY_RUN=1. |
| get_totp_codeA | Get the current TOTP code for a vault login item with TOTP configured. Returns the 6-digit code, the remaining seconds in the current period, and the algorithm. Use the remaining_seconds field to decide whether to use the code immediately or wait for a fresh period. |
| save_generated_secretA | Save an agent-generated secret into the mcp-agent-created collection. CREATE-only: cannot overwrite an existing item (name collision returns an error). The secret is E2E-encrypted with the vault org key before transmission. Sets mcp-created-by, mcp-created-at, mcp-expires-at, and mcp-used-in custom fields automatically. Blocked when READ_ONLY=1. Logs to DRY_RUN without creating a real cipher when DRY_RUN=1. |
| save_login_itemA | Save login credentials (username, password, URL, optional TOTP seed) as a Vaultwarden login item in the mcp-agent-created collection. Use this instead of save_generated_secret when the credential is a sign-in (username + password), so it surfaces as a real login item with get_totp_code support. CREATE-only: cannot overwrite an existing item (name collision returns an error). At least one of username or password is required. All fields are E2E-encrypted with the vault org key before transmission. Sets mcp-created-by, mcp-created-at, mcp-expires-at, and mcp-used-in custom fields automatically. Blocked when READ_ONLY=1. Logs to DRY_RUN without creating a real cipher when DRY_RUN=1. |
| health_checkA | Check connectivity and configuration of the Bitwarden/Vaultwarden vault. Authenticates, syncs, and reports: auth status, API version, collection visibility, item counts, latency. Run this first after a new install or after rotating credentials. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a largely distinct purpose, and descriptions explicitly cross-reference alternatives (e.g. save_login_item vs save_generated_secret, reveal_secret_via_send vs get_totp_code). The main overlap is list_vault_items vs get_vault_metadata, which both return metadata, though the descriptions clarify listing vs single-item detail.
Most tools follow a clear verb_noun pattern (list_vault_items, get_vault_metadata, reveal_secret_via_send, save_generated_secret, save_login_item, get_totp_code). health_check is the only noun-style outlier, but it is a widely conventional name, so consistency is mostly maintained.
Seven tools is well-scoped for a vault integration, covering listing, reading, revealing, writing, TOTP, and health. No tool appears redundant or filler.
Read and create operations are well covered (list, metadata, reveal, save secret, save login, TOTP, health), but the lifecycle is incomplete: there is no update, delete, or revoke operation for items or Sends. Agents cannot modify or clean up existing vault entries, which is a notable gap for a credential store.