The session management is genuinely the hard part it solves — the `bw` CLI expects an interactive human, and this makes it behave for a non-interactive caller. But the configuration includes the vault's master password in plain environment variables, which is why the README steers production users toward orchestrator secrets rather than a `.env` file. Run it somewhere you control, and start from `get_secret_template` when creating items: the item JSON has to arrive as an escaped string.
An MCP wrapper around the official Bitwarden `bw` CLI, pointed at a self-hosted Vaultwarden instance. It unlocks the vault on the first request, caches the session key, and holds a lock so concurrent calls cannot trigger competing unlocks — the part that makes the CLI awkward to automate.
- `get_secret` retrieves an item by name or by ID
- `list_secrets` searches the vault for items matching a term
- `get_secret_template` returns a JSON skeleton for a new item, with `login`, `note`, `card` and `identity` as the valid types
- `create_secret` adds an item from that JSON, and `update_secret` edits an existing one by ID
- `delete_secret` removes an item by ID
- `sync` forces the local vault to catch up with the remote server
- Session handling built in — automatic unlock with the key cached, a lock against concurrent unlocks, and timeouts so a stuck call does not block the rest
The Bitwarden CLI (`bw`) installed on the machine running the server and available on the `PATH` — every cryptographic operation goes through it. Node.js 18.0.0 or newer. Configuration is four environment variables: `BITWARDEN_HOST` for your instance URL, `BW_CLIENTID` and `BW_CLIENTSECRET` for the API credentials, and `BW_MASTER_PASSWORD`. The npm package is `mcp-vaultwarden-server`, version 1.1.1, launched with `npx`.
One command plus a key — npx mcp-vaultwarden-server, then supply credentials