Bitwarden

Sign a WebAuthn sign-in, as an authenticator does for navigator.credentials.get(): authenticator data and an ES256 signature over it and the client data's hash, with the vault's passkey for the site, plus the credential id and user handle a browser returns. With allow_credentials, only a passkey those ids name; without (a discoverable request), any discoverable passkey for the RP ID. When several can answer, the call is refused as several with the candidates: call again with credential_id. No passkey for the site is refused as no_credential. Hand the result only to the page that asked; the key never leaves this server.

Whether a login's password appears in Have I Been Pwned's list of passwords seen in data breaches, and how many times. Only the first five hex characters of the password's SHA-1 leave this server (k-anonymity); the password and its full hash never do, and the answer is a count. A count above 0 means the password is known to attackers: rotate it (update_login with rotate_password, then change it on the site). With previous, the password the current one replaced.

Save a new login. Without `password` or `password_file` a strong one is generated here and stored; nothing returns it, so call get_password when you type it into the signup form. Create the login BEFORE submitting a signup, so the password is never lost. Filed into the account's own vault, outside any collection unless `collection` names another.

Save a secret that is not a login as a new secure note: a service account's key file, an API token, a licence key. Each secret goes in a field of its own, hidden by default, typed (value) or read from a file (file), with no password length limit: up to what Bitwarden stores in a field. Nothing returns the secret: the result names each field with its length, and a file's SHA-256 and size (compare them with the source's). get_field hands a value out; get_login names the fields. Filed into the account's own vault, outside any collection unless `collection` names another. If a call fails without saying whether the note was saved, find_logins by its name before trying again.

Register a new passkey, as an authenticator does for WebAuthn's navigator.credentials.create(): an ES256 (P-256) key pair is made here, the private key stored in the vault exactly as Bitwarden's own apps store a passkey (so they can sign with it too), and the answer is what a browser needs to finish the registration: the credential id, the attestation object (format none), the authenticator data and the public key (SPKI). The private key is never in the answer. It goes into the login item_id names, else into the one login already saved for this site with this username and no passkey, else into a new login named after the site (filed like create_login). Refused as excluded when the site's exclude list names a passkey the vault holds, and as unsupported when the site accepts no ES256 key. Use it for an agent's own identity; a person's own passkeys belong on their own devices.

Remove one passkey from its login. The login and everything else in it (username, password, 2FA key) stay. The site keeps its copy of the public key, so remove the passkey there too if it should stop being offered. Not undone by anything here.

Search the vault's logins and secure notes (`kind` says which). `search` matches name, username and URL; `url` finds the logins saved for a site (its host, as Bitwarden's autofill matches). Returns ids, names, usernames and URLs, and whether each has a password and an authenticator key, never the secrets themselves. Syncs first, so an item just added in the web vault shows up.

One custom field's value, hidden ones included, from a login or a secure note: a secret that is not a password, such as a licence key or an API token, kept where a person put it. get_login names an item's fields. Use it only to type or pipe the value where it goes: never write it into a file, a commit, a message, a log or a reply.

One login or secure note in full except its secrets: name, username, URLs, collections, notes, custom fields (hidden ones by name only) and when the password last changed.

The login's password, with its username and URLs, for typing into the site. Use it only for that: never write it into a file, a commit, a message, a log or a reply. With `previous`, the password the current one replaced, from the item's history: for when a site refused a rotation that is already stored.

Check that the vault is reachable and unlocked, and say as whom: the account, the server, when it last synced, how many logins and passkeys it holds, and the organizations and collections it can file into. Run this before concluding the MCP is broken.

Import the logins that carry passkeys from a Bitwarden JSON export (not encrypted), or from one exported item: each becomes a new login here with its username, password, 2FA key, URLs, notes, custom fields and passkeys, filed like create_login. A passkey the vault already holds is skipped, and so is one this server cannot sign with (only ES256 P-256 keys sign, as in Bitwarden's apps). The answer lists what was imported and what was skipped with the reason, and the file's SHA-256 and size: compare them with the source, then delete the file, which holds private keys.

The passkeys the vault holds, each with its site (rpId and name), account (userName, userDisplayName, userHandle), credential id (base64url), counter, whether it is discoverable, when it was made, its login (itemId, itemName), the login's collections, and whether a person shared it with this account rather than the account keeping it as its own. Never a key. Syncs first.

Put a login or secure note in one collection: its collections become exactly the one named. Only between the collections of the item's own organization; an item in the account's own vault, or a collection of another organization, is refused with what to do instead. An item already in exactly that collection is left as it is (moved: false). After a move the vault is synced and the item read back, so the answer, its collections before and after, is what Bitwarden holds. Returns no secret. Nothing is deleted or copied.

Pull the vault from Bitwarden now. Reads already sync every 30 seconds; this is for right after someone changed something in the web vault.

The login's current authenticator (TOTP) code and how many seconds it stays valid, computed from the key stored on the login. If fewer than 5 seconds are left, wait and call again.

Change a login: only what is named changes. `rotate_password` generates a new password and stores it at once; change it on the site right after, with get_password, and if the site refuses, get_password with previous: true still has the old one. `url` becomes the first URL and the others stay. `append_notes` adds to the notes (recovery codes, answers) where `notes` replaces them. Set `totp_secret` when you turn on 2FA at a site, before confirming it there: the result carries the current code from the stored key. A different key already on the login is replaced only with `replace_totp`, and kept in a hidden field.