Provides tools for managing Enpass password vaults, including unlocking vaults, listing and reading entries, retrieving passwords and TOTP codes, handling attachments, and optionally creating and deleting entries.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@enpass-mcp unlock my personal vault and list all entries"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that gives an AI assistant controlled, local access to your Enpass password vaults: unlock a vault, list vaults, and list and read entries. Creating and deleting entries is possible too, but switched off until you enable it.
Runs locally over stdio. Your Enpass vault never leaves your machine, and your master password never passes through the model: it is stored in your operating system's keychain and read directly by the server.
Master passwords live in the OS keychain (macOS Keychain, Windows Credential
Manager, Linux Secret Service), not in config files, not in environment variables,
and never as a tool argument. The unlock_vault tool deliberately takes no
password parameter, so the password can never end up in the model's context or in
logs.
The vault stays local. The server reads the encrypted vault.enpassdb file
directly with SQLCipher. Nothing is uploaded anywhere.
Reads are explicit. Listing entries never returns passwords. Secrets are only
returned by get_item / get_password, when you explicitly ask for them.
Read-only unless you say otherwise. Out of the box the server cannot change
anything: the writing tools are not even advertised. Set
ENPASS_MCP_ALLOW_WRITES=1 to enable them (see Writing).
Entry passwords are, by design, returned to the assistant when you ask for them, so only connect this to an assistant and vaults you trust.
Related MCP server: protonpass-mcp
Node.js 18 or newer
An Enpass 6 / 7 / 8 vault (vault.enpassdb, SQLCipher format)
On Linux: a Secret Service provider (GNOME Keyring or KWallet) for password storage
Native dependencies (better-sqlite3-multiple-ciphers, @napi-rs/keyring) ship
prebuilt binaries for common platforms, so no compiler is required in the normal case.
git clone https://github.com/bitterdev/enpass-mcp.git
cd enpass-mcp
npm install
npm link # optional: makes the `enpass-mcp` command available globallyThis is the secure step that keeps the master password away from the model. You run it yourself; the password is typed into a hidden prompt and stored in the OS keychain.
# Find your vault files automatically
enpass-mcp discover
# Register a vault (you will be prompted for the master password)
enpass-mcp add-vault personal --path "/Users/you/Documents/Enpass/Vaults/primary/vault.enpassdb"
enpass-mcp add-vault work --path "/path/to/work/vault.enpassdb"
# With a keyfile
enpass-mcp add-vault personal --path "/path/vault.enpassdb" --keyfile "/path/vault.keyfile"
# Manage
enpass-mcp list-vaults
enpass-mcp test-unlock personal
enpass-mcp remove-vault workadd-vault verifies the password can actually unlock the vault before saving it.
The vault file is usually found at:
OS | Typical location |
macOS |
|
Windows |
|
Linux |
|
If you sync via Dropbox / OneDrive / WebDAV, point --path at the synced copy.
The server speaks MCP over stdio. Point your MCP client at enpass-mcp serve.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"enpass": {
"command": "enpass-mcp",
"args": ["serve"]
}
}
}If you did not run npm link, use the absolute path instead:
{
"mcpServers": {
"enpass": {
"command": "node",
"args": ["/absolute/path/to/enpass-mcp/src/cli.js", "serve"]
}
}
}Claude Code:
claude mcp add enpass -- enpass-mcp serveTool | Description |
| List registered vaults, whether their file exists, whether a password is stored, and whether they are unlocked. |
| Unlock a vault using the master password from the OS keychain. Takes only a vault name, never a password. |
| Lock a vault and clear its derived key from memory. |
| List entries (title, username, URL). Never returns passwords. Supports |
| Return a full entry including all field values (password, TOTP, etc.) and its attachment list. |
| Return the password and, if present, the current TOTP code of an entry. |
| Generate the current TOTP / 2FA one-time code for an entry, with seconds until it rotates. |
| List an entry's file attachments (name, size, MIME). |
| Decrypt an attachment; writes it to disk and returns the path (or base64 inline for small files). |
| List the vaults that use Enpass folder sync and whether the copy in the sync folder is newer. |
With ENPASS_MCP_ALLOW_WRITES=1 three more tools appear (see Writing):
Tool | Description |
| Create an entry, including custom fields; sensitive values are encrypted the way Enpass does it. |
| Delete an entry, or move it to the trash, leaving the tombstone Enpass uses so the deletion syncs. |
| Take in a newer copy from the sync folder, after backing up the local vault. |
list_items / get_item work for every Enpass entry type (logins, credit
cards, secure notes, identities, etc.), not just logins, and return all fields.
A typical assistant flow: list_vaults → unlock_vault → list_items → get_password.
Enpass stores each vault as a standard SQLCipher database (vault.enpassdb). The raw
encryption key is derived from your master password (optionally combined with a
keyfile) and the 16-byte salt at the start of the file:
PBKDF2-HMAC-SHA512, 100000 iterations (older vaults) or 320000 (newer vaults), the first 32 bytes used as the raw SQLCipher key
opened with cipher_compatibility 4 (Enpass 6.8+) or 3 (older vaults)
The server tries these combinations automatically, so it works across Enpass vault versions. The derived key is kept in memory only, for the lifetime of the server process, and is never written to disk or returned to the model.
References: Enpass Security Whitepaper, hazcod/enpass-cli.
Enpass encrypts every value flagged as "sensitive" a second time, underneath
SQLCipher, with a key that belongs to the entry rather than the vault. Fields
carrying that layer have itemfield.algo_version = 1:
Piece | Where | Layout |
Key and nonce |
| 44 bytes: 32-byte AES-256 key, then a 12-byte GCM nonce |
Value |
| hex of |
Additional data | the entry's uuid | hyphens stripped, hex-decoded to 16 raw bytes |
Binding the AAD to the entry uuid is what makes a value unusable if it is copied into
another entry. Enpass did not re-encrypt existing entries when it introduced this
layer, so one vault mixes ciphertext and plaintext under the same algo_version; a
value is treated as encrypted only when it has the shape of a payload (pure hex, whole
bytes, longer than the tag on its own).
A value that looks encrypted but fails authentication is returned as null with
decryptionFailed: true, never as the raw column content: stored ciphertext is a
plausible-looking string, and handing that back would silently pass off a wrong secret
as a real one.
Entries with a one-time-password secret (stored by Enpass as an otpauth:// URI)
can produce a live 2FA code: get_otp returns the current 6-digit code and the
seconds until it rotates, and get_password includes the current code alongside the
password. This lets an assistant fill both the password and the 2FA prompt.
Enpass keeps file attachments encrypted. Small files (up to 1 KB) sit inline in the
vault; larger files live in separate <uuid>.enpassattach SQLCipher files next to the
vault, each encrypted with its own key stored in the vault. export_attachment handles
both: it decrypts the file and, by default, writes it to disk and returns the path, so
it works for files of any size without pushing binary data through the model.
External-attachment handling is implemented from Enpass's documented format. If you hit
a vault whose attachments do not decrypt, please open an issue with the (non-secret)
schema of your attachment table.
Writing is switched off by default. A password vault is the last place where a tool
should be able to change data just because a model decided to, so the server starts
read-only and does not even list create_item, delete_item and sync_pull until you
turn them on:
ENPASS_MCP_ALLOW_WRITES=1Set it in the server's environment (in your MCP client config, or in the .env next to
vaults.json). Nothing else changes: reading works exactly the same either way.
Enpass must be closed while writing. The app keeps the database in memory and would write its own cached copy back over any change made underneath it. Every writing tool refuses to run while Enpass is open.
Earlier versions of this README claimed writing was impossible because recent vaults (schema version 6) crash Enpass when entries are inserted directly. The crash was real, the diagnosis was wrong. Three concrete rules make it work, all of them derived from what Enpass itself writes:
Enpass never stores NULL. The crash is EXC_BAD_ACCESS in strlen on a null
pointer: a column omitted from the INSERT defaults to NULL, and the app calls
strlen on it. Every column is written explicitly, empty strings instead of NULL.
A template has a fixed field set. login.default always carries the same nine
fields, in the same order, with the same field uids, even when most are empty.
Writing only the fields you happen to have a value for produces an entry the app
cannot render.
The per-item key is reproducible. item.key is a 32-byte AES-256 key plus a
12-byte GCM nonce, stored as hex(ciphertext || tag) with the item UUID as
additional authenticated data. Nothing in it is tied to Enpass internals, so a fresh
random key per item is fine.
Verified end to end against a real vault: written, read back, decrypted to the original, deleted, synced in both directions, and Enpass opens the vault without crashing.
Master passwords are in the OS keychain; only non-secret data (vault names and paths)
is stored in a small vaults.json:
macOS: ~/Library/Application Support/enpass-mcp/vaults.json
Windows: %APPDATA%\enpass-mcp\vaults.json
Linux: ~/.config/enpass-mcp/vaults.json
Override the directory with ENPASS_MCP_CONFIG_DIR.
Environment variables:
Variable | Effect |
|
|
| Where |
| Optional fallback master password for vaults without a keychain entry. Prefer the keychain. |
| Same, for one specific vault. |
npm test # runs against genuine SQLCipher fixtures in test/fixtures
# Rebuild the fixtures from scratch with real SQLCipher (vault + entries + attachments)
npm install --no-save @journeyapps/sqlcipher
npm run generate-fixturesCI (GitHub Actions) creates a vault from scratch with real SQLCipher, seeds entries and attachments, then runs the full read-only test suite on Node 18/20/22.
Anyone who can talk to this MCP server can read every password in a vault once it is unlocked. Only connect trusted clients.
The server does not implement Enpass sync, item history, or trashing.
The server is read-only and never modifies a vault. Creating or editing entries is intentionally not supported, because direct database writes crash recent Enpass vaults (see Why there is no write support).
This is an independent project and is not affiliated with or endorsed by Enpass.
MIT © Fabian Bitter
Decrypts a file attachment from an unlocked vault. By default it writes the file to disk and returns the path (works for any size). Set inline=true to get small files as base64 instead.
| Name | Required | Description | Default |
|---|---|---|---|
| dest | No | Destination directory (default: OS temp dir) | |
| uuid | Yes | Entry uuid (from list_items) | |
| vault | Yes | Registered vault name | |
| inline | No | Return small files as base64 instead of writing to disk | |
| attachment | Yes | Attachment name or index (from list_attachments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool decrypts, writes to disk by default, returns a path, and offers an inline base64 alternative for small files. It also notes 'works for any size' for the default mode. This goes beyond the schema's parameter list and gives useful operational context, though it does not disclose potential edge cases (e.g., what counts as 'small' or overwrite behavior).
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?
The description is two sentences long and front-loads the core purpose. The first sentence states the action and resource; the second explains the default behavior and an alternative. Every word earns its place with no filler or repetition of schema fields.
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?
For a tool with five parameters, a 100% covered schema, and no output schema, the description provides enough context: it explains the two output modes, the prerequisite of an unlocked vault, and the scalability of the default mode. It could go further by detailing error conditions or the exact return structure for inline mode, but it is not incomplete.
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?
The schema has 100% description coverage for all five parameters, so the baseline is 3. The description adds value by clarifying the behavior tied to the `inline` parameter (returns base64 instead of writing to disk) and explaining the default output path. This goes beyond the schema's brief parameter descriptions, especially for `inline` and `dest`, so a 4 is warranted.
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?
The description opens with a specific verb and resource: 'Decrypts a file attachment from an unlocked vault.' This clearly distinguishes it from sibling tools like list_attachments (which lists) and get_item (which retrieves metadata). The phrase 'file attachment from an unlocked vault' precisely scopes the operation.
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?
The description conveys when to use the tool: it requires an unlocked vault, implying a prerequisite. It also explains the two modes (default disk write vs. inline base64) and states that the default works for any size while inline is for small files. However, it does not explicitly name alternative tools or say 'use list_attachments to find attachment names,' so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a full entry from an unlocked vault including sensitive field values (password, TOTP, etc.). Use this when the user explicitly wants the credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Entry uuid (from list_items) | |
| vault | Yes | Registered vault name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose important behavioral traits: the vault must be unlocked and the returned entry includes sensitive values. However, it does not describe what happens if the vault is locked, error behavior, or return format, leaving some gaps for a sensitive-data operation.
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?
The description is two sentences with no wasted words. It front-loads the core behavior and adds a usage directive efficiently.
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?
Given the simple 2-parameter tool and no output schema, the description adequately conveys what is returned, its sensitive nature, and the prerequisite of an unlocked vault. Minor omissions like return structure and error handling are acceptable but could be enhanced.
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 coverage is 100%, meaning the parameters (vault and uuid) are already fully described in the schema. The description adds no additional parameter-level detail, so the baseline score of 3 applies.
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?
The description uses a specific verb ('Returns') and identifies a precise resource ('full entry from an unlocked vault'), while explicitly mentioning sensitive field values. This distinguishes it from sibling tools like get_password and get_otp, which target individual fields.
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?
The description clearly states when to use the tool ('when the user explicitly wants the credentials'), giving strong contextual guidance. However, it does not explicitly mention when not to use it or direct users to alternatives like get_password or get_otp for single-field extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates the current TOTP / two-factor one-time code for an entry that stores an OTP secret. Returns the code and how many seconds until it rotates, so it can be entered for 2FA.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Entry uuid (from list_items) | |
| vault | Yes | Registered vault name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains that it generates the current code and returns the code plus seconds until rotation. However, it omits behavioral details such as prerequisites (e.g., vault must be unlocked) or error behavior if the entry lacks an OTP secret, leaving some ambiguity.
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?
The description is two concise sentences, starts with the primary action, and includes the key output details. Every sentence provides useful information without unnecessary fluff.
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?
Given the tool's simplicity, the description adequately covers purpose and return value. The only missing context is implicit prerequisites (e.g., vault unlocked), but the sibling tool list (unlock_vault, lock_vault) helps fill that gap. Overall, it is complete enough for an agent to use correctly.
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 coverage is 100%, as both parameters (uuid and vault) have detailed descriptions. The description does not add parameter-level semantics beyond referring to 'an entry that stores an OTP secret,' which aligns with the uuid parameter. Baseline 3 is appropriate since the schema already handles parameter meaning.
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?
The description clearly states the tool's function with a specific verb ('Generates') and resource ('current TOTP / two-factor one-time code'). It also distinguishes from siblings like get_password by focusing on OTP entries and describing the return value, making the purpose unambiguous.
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?
The description provides clear context by specifying it is for 'an entry that stores an OTP secret,' indicating when the tool should be used. However, it does not explicitly mention alternatives or when not to use it, so it stops short of providing explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns just the password (and TOTP if present) of an entry in an unlocked vault.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Entry uuid (from list_items) | |
| vault | Yes | Registered vault name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the limited scope ('just the password') and conditional TOTP return ('if present'), but does not describe failure modes (e.g., locked vault, missing entry) or any side effects. Basic behavior is covered, but not deep context.
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?
The description is a single sentence that is front-loaded with the key verb and object, with no filler or redundancy. It earns its place by being directly informative.
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?
For a simple 2-parameter tool with no output schema, the description adequately explains the return content and prerequisite (unlocked vault). Minor gaps include lack of information about return format or error behavior, but overall it is reasonably complete for the tool's simplicity.
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 100%, so the schema already thoroughly documents both parameters (uuid from list_items, vault name). The description adds no additional semantic meaning beyond the schema, so baseline 3 is appropriate.
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?
The description uses a specific verb ('Returns') and a clear resource ('the password (and TOTP if present) of an entry in an unlocked vault'). It distinguishes from siblings like get_item by emphasizing 'just the password' and from get_otp by indicating TOTP inclusion when present.
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?
The phrase 'in an unlocked vault' conveys a clear prerequisite context for use. However, it does not explicitly mention alternative tools or when not to use this tool, though the 'just' phrasing implies using get_item for full details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the file attachments of an entry in an unlocked vault (name, size, MIME). Use export_attachment to get the file itself.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Entry uuid (from list_items) | |
| vault | Yes | Registered vault name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful context: the vault must be unlocked, and the output includes name, size, and MIME. However, it does not mention whether this is a read-only operation, what happens if the vault is locked, or any error behavior. It is adequate but not deeply transparent.
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?
The description is concise: two sentences, each with a clear purpose. The first sentence states the action and output, the second gives an alternative. No unnecessary words or repetition.
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?
For a simple two-parameter tool with no output schema, the description covers the core aspects: what it does, what it returns, a prerequisite (unlocked vault), and an alternative tool for a different use case. It lacks edge-case details (e.g., behavior when the vault is locked), but for a listing tool this is sufficient.
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?
The input schema already has 100% description coverage for both parameters ('vault' and 'uuid'). The description adds the qualifier that the vault must be unlocked, which provides slight additional meaning, but it does not significantly enhance the parameter semantics beyond what the schema already conveys. Baseline 3 is appropriate.
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?
The description clearly states the tool's function: 'Lists the file attachments of an entry in an unlocked vault (name, size, MIME).' It uses a specific verb ('lists') and resource ('file attachments of an entry'), and explicitly distinguishes it from the sibling tool 'export_attachment' by noting that the latter is for getting the file itself.
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?
The description provides explicit usage guidance: it says to use 'export_attachment' to get the file itself, implying this tool is for listing metadata (name, size, MIME). It also specifies the prerequisite that the vault must be unlocked, which tells the agent when the tool can be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists entries in an unlocked vault. Returns titles, usernames and URLs but no passwords or other sensitive values. Supports optional search, category and folder filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 200) | |
| query | No | Case-insensitive search across title, username and URL | |
| vault | Yes | Registered vault name | |
| folder | No | Filter by folder title or uuid | |
| category | No | Filter by category, e.g. login, creditcard, note |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: requires an unlocked vault, returns only non-sensitive fields, and supports filters. It does not mention pagination or error behavior, but for a read-only listing tool, the disclosure is adequate and goes beyond basic scope.
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?
The description is two sentences: the first states function and output scope, the second states filters. Every word earns its place, with no redundancy or fluff. Information is front-loaded and immediately usable.
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?
Given no output schema and no annotations, the description adequately covers return values (titles, usernames, URLs), constraints (unlocked vault, no sensitive data), and filter options. It omits default limit, but that is covered by the schema. For a simple list tool, this is sufficiently complete.
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 coverage is 100%, with each parameter having a descriptive comment. The description mentions 'optional search, category and folder filters' which aligns with query, category, and folder params, but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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?
The description states a specific action ('Lists entries') and a clear resource ('in an unlocked vault'). It distinguishes from siblings like list_vaults (lists vaults) and get_item (single entry) by focusing on entry listings, and clarifies it returns only titles/usernames/URLs, not passwords, setting it apart from get_password.
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?
The description implies when to use it: after unlocking a vault, for non-sensitive entry listings. It also provides a when-not by explicitly excluding passwords/sensitive values, implicitly steering to other tools. However, it does not name alternative tools explicitly or state exclusions like 'use get_item for details', so it's clear context without full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the Enpass vaults registered on this machine, whether their file exists, whether a master password is stored in the OS keychain, and whether they are currently unlocked in this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral transparency burden. It explains what the tool reports: file existence, keychain storage of master password, and session unlock state. This goes beyond a generic 'list vaults' and informs the agent about latent checks without requiring external knowledge.
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?
The description is a single sentence that packs multiple relevant details without unnecessary words. It is front-loaded with the primary action and scope, and each clause adds value to the agent's understanding.
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?
For a simple 0-parameter tool with no output schema, the description sufficiently explains what the returned data covers (vault registration, file existence, keychain status, unlock state). It does not specify the exact return format, but the key attributes are enumerated, which is adequate for an agent to know what to expect.
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?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on behavior rather than parameters, and no parameter documentation is needed.
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?
The description uses a specific verb ('Lists') and clearly identifies the resource ('Enpass vaults registered on this machine'). It distinguishes the tool from siblings like list_items by scoping to vault-level metadata rather than items or attachments.
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?
The description implies when to use the tool (when needing vault registration/status info) but does not explicitly state alternatives or exclusions relative to sibling tools. It lacks phrases like 'use this instead of' or 'when you need' that would provide stronger guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locks a vault and clears its derived key from memory for this session.
| Name | Required | Description | Default |
|---|---|---|---|
| vault | Yes | Registered vault name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a mere action verb by revealing a key side effect: clearing the derived key from memory for this session. This adds meaningful context about session-scoped behavior and memory impact, though it stops short of detailing reversibility or effects on other vault data.
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?
The description is a single, well-structured sentence that front-loads the primary action ('Locks a vault') and appends a critical behavioral detail. Every word earns its place, with zero redundancy or filler.
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?
For a simple one-parameter tool with no output schema, the description sufficiently covers the action and a key behavioral consequence. The session-scoped caveat is useful, though it could slightly benefit from mentioning whether the lock is temporary or affects other sessions. Overall, it is adequately complete for the tool's simplicity.
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?
The schema provides 100% coverage for the single parameter 'vault' with the description 'Registered vault name', so the description does not need to add much. However, the tool description itself offers no extra clarification about the parameter, keeping it at baseline without enhancing meaning beyond the schema.
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?
The description uses the specific verb 'Locks' with the resource 'vault' and adds a distinctive behavioral detail: it clears the derived key from memory for this session. This clearly distinguishes it from sibling tools, especially unlock_vault, making the purpose unmistakable.
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?
The description conveys when to use the tool by stating its action ('Locks a vault'), and the sibling list includes unlock_vault, implying this is the inverse operation. However, it does not explicitly mention alternatives, prerequisites, or scenarios where locking is appropriate or discouraged, leaving usage guidance largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every vault that uses Enpass folder sync, where its sync folder is, and whether the copy there is newer than the local one. Vaults without folder sync are not listed. Answers include a reason, so 'no baseline yet' is distinguishable from 'up to date'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It goes beyond a simple 'lists sync status' by detailing that it reports the sync folder location, compares local vs. remote copy timestamps, and includes a reason in answers, allowing distinctions like 'no baseline yet' vs 'up to date'.
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?
The description is two sentences, front-loaded with the main action, and every clause adds essential information: scope (vaults with folder sync), details (folder path, newer copy), and answer characteristics (include reason). No wasted words.
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?
For a zero-parameter tool with no output schema or annotations, the description is complete enough. It defines what is listed, what is excluded, and what kind of answers to expect. It does not explain the exact return format, but given the simplicity, this is not a critical gap.
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?
There are no parameters, so the description has no parameter details to add. The baseline score of 4 is appropriate because no parameter documentation is needed.
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?
The description uses the specific verb 'Lists' and clearly identifies the resource: vaults using Enpass folder sync. It also distinguishes itself from sibling list_vaults by stating that vaults without folder sync are not listed, making its purpose distinct.
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?
The description clearly indicates the tool's scope (folder sync status) and notes that vaults without folder sync are not included, which implies when to use it. However, it does not explicitly name an alternative tool such as list_vaults for all vaults, so it lacks explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlocks a registered vault using the master password stored in the OS keychain. The password is never passed as an argument and never reaches the model. Must be called before listing or reading entries.
| Name | Required | Description | Default |
|---|---|---|---|
| vault | Yes | Registered vault name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral traits: the master password is retrieved from the OS keychain, never passed as an argument, and never reaches the model. It also states a prerequisite ordering. This adds valuable context beyond the schema, though it does not mention potential side effects or error states.
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?
The description is two sentences long, front-loaded with the core action, and every sentence earns its place. It efficiently covers purpose, security handling, and usage requirement without any unnecessary words.
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?
For a simple one-parameter, no-output tool, the description is complete. It explains what the tool does, the security model for the password, and the required call order. The agent has enough context to select and invoke the tool correctly. No output schema is needed for a void operation.
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 coverage is 100% with the single parameter 'vault' described as 'Registered vault name'. The description adds little beyond that, only implying that the vault must be registered. It does not provide examples or clarify how to obtain the vault name, but the schema already handles the semantics adequately.
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?
The description clearly states the tool's function: 'Unlocks a registered vault.' The verb 'unlocks' and the resource 'vault' are specific, and it distinguishes itself from siblings like lock_vault and list_vaults.
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?
The description provides explicit usage guidance: 'Must be called before listing or reading entries.' This tells the agent when to use the tool. It does not explicitly mention exclusions or alternatives (e.g., when vault is already unlocked), but the requirement is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0export_attachmentget_itemget_otpget_passwordlist_attachmentslist_itemslist_vaultslock_vaultsync_statusunlock_vaultEach tool has a clearly distinct purpose: vault status management (list_vaults, unlock_vault, lock_vault), item retrieval (list_items, get_item, get_password, get_otp), attachment handling (list_attachments, export_attachment), and sync tracking (sync_status). No two tools overlap in function.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., list_vaults, unlock_vault, get_password, export_attachment). The verb is always listed first and the noun is specific, making the naming predictable and readable.
With 10 tools, the server is well-scoped for its purpose. It covers vault lifecycle, item queries, OTP generation, attachments, and sync status without unnecessary bloat or sparse coverage.
The toolset fully covers read and credential-retrieval workflows, including attachments and OTP. However, there are no create, update, or delete operations for items, which may be intentional for security but limits management functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitterdev/enpass-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
