Bitwarden

Bitwarden MCP server

Give your AI assistant a Bitwarden account of its own to sign up and sign in with. It finds, creates and updates logins, generates passwords and hands one out only to type it, computes 2FA codes, keeps other secrets (an API token, a key file) in secure notes, moves items between an organization's collections, and checks passwords against Have I Been Pwned. It is also a passkey authenticator: it registers passkeys and signs WebAuthn sign-ins with them, stored the way Bitwarden's own apps store passkeys, so either can use the other's. create_login, update_login, create_note, move_item, create_passkey and import_passkeys write; delete_passkey removes one passkey from its login, and nothing else deletes. Nothing exports or changes settings, and no tool is money.

You need a Bitwarden account set aside for the agent, not your personal vault (any plan: Premium is not needed), with its personal API key and master password each in a file. Every call runs Bitwarden's CLI, so tools take seconds, not milliseconds. The account is for the agent's own identities: your own passkeys belong on your own devices.

What you can ask

• "Create a login for example.com with the username bot@example.com and a 32-character password without symbols."
• "Which logins do we have saved for example.com?"
• "What is the current 2FA code for the Example Shop login?"
• "Generate a new password for the Example Shop login, and keep the old one in case the site refuses the change."
• "Is the password of any of our Example Cloud logins in a known breach?"
• "Store the key in example-key.json as a secure note called 'Example Cloud deploy key'."
• "Move the Example Shop login into the Shared collection."
• "Which passkeys does the vault hold for example.com?"
• "Import the passkeys in example-export.json, then delete the file."

Install

With Claude Code:

claude mcp add bitwarden -e BITWARDEN_CLIENT_ID_FILE="<path to API key client id file>" -e BITWARDEN_CLIENT_SECRET_FILE="<path to API key client secret file>" -e BITWARDEN_MASTER_PASSWORD_FILE="<path to Master password file>" -- npx -y @foreverworks/mcp-bitwarden

Claude Desktop (Settings, Developer, Edit Config) and most other clients read the same command as JSON:

{

"mcpServers": { "bitwarden": { "command": "npx", "args": ["-y", "@foreverworks/mcp-bitwarden"], "env": { "BITWARDEN_CLIENT_ID_FILE": " ", "BITWARDEN_CLIENT_SECRET_FILE": " ", "BITWARDEN_MASTER_PASSWORD_FILE": " " } } } }

Each runs the published package on Node 22.19 or newer. VS Code and the Claude Desktop bundle ask for each setting as they add the server; leave an optional one empty. Cursor reads each from your environment instead (${env:BITWARDEN_CLIENT_ID_FILE} and so on), so set them before you start Cursor. The commands above set only what is required; Configuration has the rest.

From a clone

git clone https://github.com/foreverworks/mcps.git && cd mcps

npm ci && npm run build claude mcp add bitwarden -e BITWARDEN_CLIENT_ID_FILE=" " -e BITWARDEN_CLIENT_SECRET_FILE=" " -e BITWARDEN_MASTER_PASSWORD_FILE=" " -- node "$PWD/servers/bitwarden/dist/index.js"

In a JSON configuration, the command is node and its one argument the full path of servers/bitwarden/dist/index.js. To share one running copy between several clients over HTTP, see docs/deploying.md.

The official CLI, @bitwarden/cli (pinned to 2026.10.0), is a dependency of the package: npx and npm ci install it with the server, which runs it under its own Node and never uses a bw on your PATH.

Configuration

BITWARDEN_CLIENT_ID, BITWARDEN_CLIENT_SECRET and BITWARDEN_MASTER_PASSWORD are read only when their _FILE twin is unset. Prefer the files: a variable is visible to every process of the same user. A named file that is missing or empty is a config error, never a fallback to the variable. Without the secrets the server still starts and lists its tools, and each call answers a config error naming what is missing.

password_file, a note field's file and the export import_passkeys takes are read from MCP_FILE_ROOTS; that and the other variables every server shares are in docs/configuration.md.

Getting the API key and master password

1. Create a Bitwarden account for the agent, on any plan, with a strong master password. Keep a copy where a person can recover it.
2. In the web vault, open Settings, Security, Keys, and choose View API key.
3. Write the client_id (it looks like user. ) to the first file, the client_secret to the second, and the master password to the third, each readable by the server's user only.
4. Optionally, create a free organization with a collection for the agent's logins, set BITWARDEN_DEFAULT_COLLECTION to it, and invite your own account. You then see what the agent saves, and can lend it a login by putting it in a second collection.

First run

1. Ask your assistant to run Bitwarden's health check. It answers with the account's email, the server, the last sync, how many logins the vault holds, and the organizations and collections it can file into. The first call after a start logs in, unlocks and syncs, so it is the slowest. A refused API key or master password shows up here as auth.
2. To sign up somewhere, the assistant calls create_login first, so the password is stored before the site sees it, then get_password to type it.
3. Passkeys need a program in the browser's place: whatever handles the site's WebAuthn request (a browser extension, an automation driver) builds the client data, checks the site's RP ID against the page's origin, and calls create_passkey or assert_passkey with the client data's hash. The answer is what a browser hands back to the page.

Tools

read changes nothing in the vault; write adds an item or changes one. Only delete_passkey removes anything: one passkey, from a login that stays.

Logins and notes

Passkeys

| assert_passkey | read | Sign a WebAuthn sign-in for