What can you do with this server?

The wundervault server provides a zero-knowledge secrets vault for AI agents, decrypting and injecting secrets server-side without ever exposing plaintext to the agent or model context. * List vault entries (vault_entries_list): Retrieve all accessible vault entry IDs and names — never secret values. * Retrieve a vault secret (vault_entry_get): Decrypt a secret server-side for a stated, audit-logged purpose; the agent only receives "Secret retrieved and burned." — plaintext is never returned. * Discard a vault reference (vault_entry_forget): Remove a stale entry reference from the agent's local context; no effect on the server vault. * Inject a secret into a .env file (vault_entry_inject_env): Decrypt a secret and write it directly into a specified variable in a .env file on disk — plaintext never returned to the agent. * Execute a command with secret injection (vault_exec): Run a shell command locally or remotely (via SSH) with a vault secret injected as an environment variable; supports pre/post commands and SSH key injection, with shell escape patterns explicitly blocked. * Sync files via rsync (vault_rsync): Transfer a local directory to a remote host over SSH using a vault-stored SSH key, which is written to a temp file only for the duration of the transfer and deleted immediately after.

Which integrations are available for this server?

Allows injecting secrets into Docker configuration by writing to ~/.docker/config.json, enabling agents to manage Docker registry credentials securely. Allows injecting secrets into .env files for environment variable configuration, enabling agents to manage application secrets without exposing them. Allows injecting secrets into npm configuration by writing to ~/.npmrc, enabling agents to manage npm authentication tokens securely.

wundervault

Official

by wundervault

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@wundervault/mcp-server

npm version MCP Registry License: AGPL-3.0

A zero-knowledge secrets vault for AI agents. Every API key you paste into an agent chat or a .env file ends up in context windows, transcripts, and provider logs. Wundervault's answer: the agent never receives the secret at all. It asks for work — "run this deploy with the key injected" — and a local daemon decrypts the secret, injects it into the subprocess environment, zeroes the buffer, and scrubs the output before the agent sees any of it.

This repo is the MCP server that exposes that workflow to any Model Context Protocol client — Claude Code, Cursor, Cline, and others.

Don't trust the claim — test it: the zero-knowledge property is independently verifiable at your own network boundary in about 5 minutes (browser DevTools or a mitmproxy canary test). Guide + our own test transcript: wundervault.com/verify.

How it works

┌──────────────┐  MCP (stdio)  ┌───────────────────┐  ciphertext only  ┌───────────────────┐
│   AI agent   │──────────────▶│  wundervault-mcp  │◀─────────────────▶│  wundervault.com  │
│ (Claude, …)  │◀──────────────│  + local daemon   │                   │ stores encrypted  │
└──────────────┘ "burned" ack  │  decrypts HERE    │                   │ blobs, no keys    │
                               └─────────┬─────────┘                   └───────────────────┘
                                         │  secret → subprocess env
                                         │  (buffer zeroed after spawn)
                                         ▼
                               ┌───────────────────┐
                               │   your command    │ stdout/stderr scrubbed
                               │ (deploy, API, …)  │ before the agent sees it
                               └───────────────────┘

Secrets are encrypted client-side (AES-256-GCM via Web Crypto) before upload. The hosted service only ever stores ciphertext — it cannot derive the key, the passphrase, or the plaintext.

Related MCP server: Warden MCP Server

Install

npm install -g @wundervault/mcp-server

Quick Start

{
  "mcpServers": {
    "wundervault": {
      "command": "wundervault-mcp",
      "env": {
        "WUNDERVault_AGENT_VAULT_URL": "https://wundervault.com",
        "WUNDERVault_AGENT_VAULT_API_KEY": "wv_agent_<AGENT_ID>|<KEY_SUFFIX>",
        "WUNDERVault_AGENT_KEY": "<BASE64_ENCRYPTION_KEY>"
      }
    }
  }
}

Or using a credentials file:

wundervault-mcp --credentials ~/.wundervault/creds.json

New account? wundervault.com has a 90-second agent onboarding flow that generates this config for you.

Security Model

Zero-knowledge: The encryption key lives only in the MCP server process. The Wundervault server never sees it.
Burn-after-reading: Plaintext secrets are never returned to the calling agent. After decryption, the agent receives only "Secret retrieved and burned.".
Exec scrubbing: Command stdout/stderr are scrubbed of the plaintext before being returned; shell-escape patterns ($(), backticks, sh -c, eval) and file redirects of secrets are rejected before decryption.
Directive integrity: Server-side directive signatures (PBKDF2-HMAC-SHA256, 600k iterations) are verified before any secret is released.
Timing-safe: HMAC comparison uses crypto.timingSafeEqual.
Tiered access: Per-entry access tiers are enforced server-side; high-tier secrets require human approval before an agent can use them.

Honest limitations

The platform is open-core: this MCP server and the browser crypto are AGPL-3.0 so you can audit everything that touches your secrets, but the hosted service itself is not open source.
A local daemon must run next to the agent; fully air-gapped setups don't fit.
By design the agent can never read a secret's value — if your workflow needs the model to reason about the secret itself, this is the wrong shape.

Tools

`vault_entries_list`

List all vault entries available to this agent. Returns entry IDs and secret names — no values.

Input: {}
Output: "Vault entries (N):\n  [entry_id]  secret_name  (tier: read)"

`vault_entry_get`

Retrieve and decrypt a vault secret. Optionally execute a command with it.

Input:
  entry_id: string          # from vault_entries_list
  purpose: string           # audit log reason
  exec?: string             # optional shell command

Output: "Secret retrieved and burned." (plaintext NEVER returned)

Secure exec pattern (sudo example):

sudo -S systemctl restart nginx <<< "$WUNDERVault_SECRET"

Do NOT use echo $WUNDERVault_SECRET | sudo -S — that exposes the secret in process logs.

`vault_exec`

Execute a shell command with a vault secret injected as an env var — locally or on a remote host over SSH. The secret is injected into the subprocess and the buffer is zeroed immediately after spawn; escape patterns are rejected before decryption.

Input:
  purpose: string           # audit log reason
  command: string           # full shell command (no escape patterns)
  entry_id?: string         # secret to inject (omit for SSH-key-only remote exec)
  working_dir?: string
  inject_as?: { env_key, pre_command?, post_command? }   # override entry's exec_config
  remote_host?: { host, user, ssh_key_entry_id? | ssh_key? }

With remote_host.ssh_key_entry_id, the SSH key is fetched from the vault and used without ever being written to disk.

`vault_entry_inject_env`

Write a vault secret directly into a config file (~/.npmrc, ~/.netrc, ~/.docker/config.json, or a project .env) without the plaintext passing through the agent.

Input:
  entry_id: string
  purpose: string
  file_path: string         # allowed config file paths only
  env_key: string           # variable name to set

`vault_rsync`

Sync a local directory to a remote host using rsync over SSH, with the SSH key fetched from the vault (temp keyfile deleted immediately after transfer).

`vault_entry_forget`

Discard a local reference. No-op on the server.

Input: { entry_id: string }
Output: "Reference [id] discarded from local context."

Credential Loading Priority

CLI flags (--api-key, --enc-key, --url)
Environment variables (WUNDERVault_AGENT_VAULT_API_KEY, WUNDERVault_AGENT_KEY, WUNDERVault_AGENT_VAULT_URL)
WUNDERVault_CREDENTIALS_FILE env var (explicit path)
~/.wundervault/creds.json
~/.config/wundervault/credentials (XDG)

Credentials file format

{
  "agent_vault_url": "https://wundervault.com",
  "agent_vault_api_key": "wv_agent_<ID>|<SUFFIX>",
  "agent_encryption_key": "<BASE64_URL_SAFE_32_BYTES>"
}

CLI Options

wundervault-mcp [options]

  --api-key <key>     Agent API key
  --enc-key <key>     Encryption key (base64 URL-safe)
  --url <url>         API base URL (default: https://wundervault.com)
  --credentials <f>   Path to credentials JSON file
  --help              Show help

Agent wallets (x402)

An x402 payment is just a signature, and a wallet key is a vault secret like any other. Store the key at tier 2, have the agent sign the payment payload through vault_exec, and the key is injected into a local signing subprocess — it never enters the model context, and every use needs the owner's approval first (the agent's denied call carries a request id; approval is scoped to that agent + secret, once or for a 15/60-minute window). We ran this end-to-end on Base Sepolia — the verified run is written up at wundervault.com/agent-wallets. Payment-specific policy (spend caps, payee allowlists) is not built yet: compatible, not productized.

Sandbox / demo mode

Set WUNDERVAULT_MOCK=1 to run the server without a wundervault-agent daemon or any credentials. In this mode every tool call returns a representative response clearly labelled [DEMO MODE] instead of contacting the vault — no real secret is ever involved. This exists so you can poke at the tool surface without an account, and so MCP directory scanners and CI (e.g. Glama) can start the server, exercise each tool, and validate the build with no live vault. It is off by default and is never enabled in production.

"env": { "WUNDERVAULT_MOCK": "1" }   // demo/CI only — returns fake, labelled output

Building from source

git clone https://github.com/wundervault/wundervault-mcp.git
cd wundervault-mcp
npm install
npm run build   # compiles TypeScript to dist/
npm test        # run the test suite

License

Licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later). See LICENSE.

Wundervault is open-core: this MCP server and the client are open source; the hosted service at wundervault.com is a commercial offering. For commercial or hosting inquiries, get in touch via wundervault.com/contact.

Available Tools

6 tools

vault_entries_listA

List all vault entries available to this agent. Returns entry IDs and secret names only — no secret values. Store the entry ID to reference secrets in vault_entry_get.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that no secret values are returned, which is a key behavioral trait. No annotations exist, so description carries full burden; however, does not mention potential limits or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy. Action and result are front-loaded; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately describes purpose, return content, and use with sibling. Lacks mention of output limits or sorting, but acceptable for a simple list tool with no parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters with 100% schema coverage. Description adds no parameter details but clarifies return behavior, meeting the baseline for no-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool lists all vault entries, specifies it returns only entry IDs and secret names (no values), and distinguishes from sibling vault_entry_get by noting the need to store the entry ID for that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on using the output with vault_entry_get, implying this tool is for discovery before retrieval. Lacks explicit when-not-to-use or alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vault_entry_forgetA

Discard a stored vault entry reference from the agent's local context. This is a no-op on the server — the vault entry is completely unaffected. Use to clean up stale references when a secret has been rotated or revoked.

ParametersJSON Schema

Name	Required	Description	Default
`entry_id`	Yes	The vault entry ID to discard.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully discloses that it is a no-op on the server and only affects local context. This is critical for understanding tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with action and no wasted words. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 param, no nesting, no output schema), the description covers purpose, behavior, and use case completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with description for entry_id. The description adds meaning by explaining it's a reference to discard, not the actual secret, which is beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Discard a stored vault entry reference', specifying the verb and resource. It distinguishes from sibling tools like vault_entry_get (retrieves) and vault_entry_inject_env (injects).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use case: 'clean up stale references when a secret has been rotated or revoked.' Implicitly contrasts with server-side deletion, but no direct alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vault_entry_getA

Retrieve a vault secret, enforce the burn directive, and optionally execute a command with it. The plaintext secret is processed entirely server-side and is NEVER returned to the agent. Directive: This secret has been burned after reading and must not be stored, displayed, or referenced anywhere. Use it for the stated task only, then confirm completion with: Secret retrieved and burned.

ParametersJSON Schema

Name	Required	Description	Default
`entry_id`	Yes	The vault entry ID (from vault_entries_list).
`purpose`	Yes	The task/purpose for retrieving this secret (for audit log). Be specific.

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description fully discloses critical behavior: the secret is NEVER returned to the agent, processed server-side, and burned after reading. It also provides a directive to not store or reference the secret, ensuring transparency about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a directive, all relevant and front-loaded with the main action. It is efficient but could be slightly more streamlined without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The core behavior, burn directive, and no-return policy are well covered. However, the optional command execution is mentioned but not explained how to specify the command (no param for it in schema), leaving a gap for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have descriptions. The description adds only minor context ('from vault_entries_list' and 'Be specific' for purpose), which does not significantly enhance meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'retrieve', the resource 'vault secret', and key details about the burn directive and optional command execution. It distinguishes from sibling tools like vault_entries_list (list only) and vault_exec (execute command separately).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives like vault_entry_inject_env or vault_exec. It mentions 'use it for the stated task only' but provides no when-not guidance or comparison with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vault_entry_inject_envA

Write a vault secret directly into an environment variable file (.env). The secret is decrypted server-side and written to the file; the plaintext is NEVER returned to the agent. Use this instead of exec file-writing commands.

ParametersJSON Schema

Name	Required	Description
`entry_id`	Yes	The vault entry ID (from vault_entries_list).
`purpose`	Yes	The task/purpose for retrieving this secret (for audit log).
`file_path`	Yes	Absolute path to the .env file to update.
`env_key`	Yes	The environment variable name to set, e.g. LISTMONK_ADMIN_PASSWORD.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry burden. Clearly discloses that the secret is decrypted server-side and written directly, and that plaintext is never returned to the agent – critical security behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two highly informative sentences. Front-loaded with action. Zero waste – every sentence adds value (purpose, security behavior, usage advice).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 required parameters, no output schema, and simple write operation, the description fully covers purpose, behavior, security, and usage guidance. No gaps for an AI agent to correctly invoke.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, baseline 3. Description adds no additional meaning beyond what schema already provides for each parameter. It gives overall context but no per-parameter enrichment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Write a vault secret directly into an environment variable file (.env)' – specific verb+resource+target. Explicitly distinguishes from sibling tool 'vault_exec' with 'Use this instead of exec file-writing commands.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use this tool ('Use this instead of exec file-writing commands') and describes a key behavior (plaintext never returned). No ambiguity about context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vault_execA

Execute a shell command with a vault secret injected as an env var. The secret is never returned to the agent — it is injected into the subprocess and the Buffer is zeroed immediately after spawn.

Tier 1 and Tier 2 secrets execute automatically based on server-side access policy.

The vault entry's exec_config (set in dashboard) provides the injection recipe (env_key, pre_command, post_command). You may override it with inject_as if needed. For LOCAL exec an injection recipe is required; for REMOTE exec it is optional.

To run a remote command using only a vaulted SSH key (no secret injected), omit entry_id and pass remote_host with ssh_key_entry_id.

NEVER use shell escape patterns in command ($(), backticks, bash -c, sh -c, eval) — these are rejected before the secret is decrypted.

ParametersJSON Schema

Name	Required	Description
`entry_id`	No	Vault entry ID (from vault_entries_list) of the secret to inject. Optional: omit it to run a remote command using only a vaulted SSH key (remote_host.ssh_key_entry_id) with no secret injected.
`purpose`	Yes	Why this secret is needed (audit log).
`command`	Yes	Full shell command to run (no escape patterns).
`working_dir`	No	Optional working directory for the command.
`inject_as`	No	Override exec_config injection recipe. Omit to use vault entry's exec_config.
`remote_host`	No	Run the command on a remote machine via SSH. The secret is injected inside the remote shell via SSH stdin — no AcceptEnv/SendEnv configuration required on the remote host. Use ssh_key_entry_id (preferred) to load the SSH key from the vault so it is never exposed on the filesystem. Use ssh_key as a fallback path if the key is already on disk.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses critical security behaviors: secret never returned, buffer zeroed, injection via exec_config, and rejection of escape patterns. Explains remote SSH key handling without disk exposure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficiently structured with primary purpose first, then security, then execution details, and finally constraints. No superfluous sentences; every sentence contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 params, nested objects, no output schema), the description thoroughly covers execution modes, security, injection, and constraints. No gaps for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already covers 100% of parameters with descriptions. The description adds value by explaining the overall flow, when parameters are optional, and how inject_as overrides work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute a shell command with a vault secret injected as an env var.' It specifies the action, resource, and security context, distinguishing it from other vault tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use, when-not (omit entry_id for remote-only), and prohibitions (no shell escape patterns). Also distinguishes between LOCAL and REMOTE execution modes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vault_rsyncA

Sync a local directory to a remote host using rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the duration of the transfer and deleted immediately after. Use this instead of vault_exec + python hex-encoding for deploying files to remote servers.

ParametersJSON Schema

Name	Required	Description
`ssh_key_entry_id`	Yes	Vault entry ID containing the SSH private key.
`purpose`	Yes	Why this transfer is happening (audit log).
`local_path`	Yes	Local source path. Trailing slash syncs contents; no trailing slash syncs the directory itself.
`remote_user`	Yes	SSH username on the remote host.
`remote_host`	Yes	Remote hostname or IP address.
`remote_path`	Yes	Destination path on the remote host.
`extra_args`	No	Additional rsync flags, e.g. ["--delete", "--exclude=*.pyc"]. Optional.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It discloses a key behavioral trait: the SSH key is written to a temp file for the duration of the transfer and deleted immediately after. This is important security context. It does not mention other behavioral aspects like whether the operation is destructive or rate limits, but the key handling disclosure is sufficient for a score of 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, no wasted words. The first sentence packs the purpose and a key behavioral note, and the second sentence gives a usage recommendation. It is efficiently structured and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and 7 parameters, the description covers the essential inputs and key behavior. It could optionally mention what the tool returns (e.g., success/error or rsync output), but this is not critical. Overall, it provides sufficient context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 7 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds meaningful extra context: the trailing slash behavior for local_path (contents vs directory sync) and notes extra_args as optional. This additional information warrants a score of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool syncs a local directory to a remote host using rsync over SSH with a vault-fetched SSH key. It specifies the verb 'sync', the resource 'local directory to remote host', and the method 'rsync over SSH'. It also explicitly contrasts with the sibling tool vault_exec + python hex-encoding for deploying files, providing a clear distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to use this tool instead of vault_exec + python hex-encoding for deploying files to remote servers, giving clear usage context. However, it does not elaborate on when not to use it or other alternatives, which prevents a score of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jun 16, 2026
- First observedvault_entries_list
- First observedvault_entry_forget
- First observedvault_entry_get
- First observedvault_entry_inject_env
- First observedvault_exec
- First observedvault_rsync

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Most tools target distinct operations: listing, forgetting, retrieving+executing, injecting to .env, executing with env var, and rsync over SSH. There is a slight overlap between vault_entry_get and vault_exec, as both can execute commands with secrets, but get includes a burn directive and does not return the secret, while exec is more general.

Naming Consistency3/5

The naming pattern is inconsistent: some tools use the prefix vault_entry_ followed by a verb (list, forget, get, inject_env), while others use vault_ directly (vault_exec, vault_rsync). Additionally, vault_entries_list uses plural 'entries' instead of singular 'entry', and vault_rsync is a proper noun. The verbs are not uniformly structured.

Tool Count4/5

With 6 tools, the set is well-scoped for a vault management server focused on secret consumption. It covers the essential actions an agent needs (list, forget, use secrets via exec/inject/rsync), without being overly large or sparse.

Completeness3/5

The tool set lacks create, update, or delete operations for vault entries, which may be handled externally. However, the existing tools cover the core workflows of listing and using secrets (via exec, inject_env, rsync), with a burn directive for secure handling. The absence of a tool to simply retrieve a secret value is intentional for security, but limits flexibility.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

Vault MCP Server
Security Databases Developer Tools
kelleyblackmore
A
license
A
quality
D
maintenance
Enables interaction with HashiCorp Vault to read, write, list, and delete secrets through a containerized MCP server with secure token-based authentication.
Updated 10 months ago (2025-11-01 09:01 UTC)
4
11
MIT
Warden MCP Server
Security App Automation Developer Tools
icoretech
A
license
A
quality
A
maintenance
MCP server for Vaultwarden/Bitwarden vault management. Enables AI agents to securely create, search, read, and update vault items via the official Bitwarden CLI, with safe-by-default redaction and support for both stdio and SSE transports.
Updated a day ago (2026-09-05 04:35 UTC)
53
904
14
MIT
Agentic Vault
Security Shell Access
AliProgrammin
A
license
Not graded
quality
C
maintenance
MCP server that lets AI agents call APIs without ever seeing the credentials, using a local encrypted vault and per-secret allowlist policies for HTTP requests and subprocess environment variables.
Updated 4 months ago (2026-04-26 15:14 UTC)
1
AGPL 3.0
AgentValetofficial
Security Autonomous Agents
AgentValet
A
license
A
quality
A
maintenance
Identity and credential governance for AI agents. Every agent gets its own cryptographic identity, scoped short-lived credentials per platform, human approval on sensitive actions, and an immutable audit log.
Updated 25 days ago (2026-08-12 11:13 UTC)
7
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wundervault/wundervault-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@wundervault/mcp-server

How it works

Install

Quick Start

Security Model

Honest limitations

Tools

vault_entries_list

vault_entry_get

vault_exec

vault_entry_inject_env

vault_rsync

vault_entry_forget

Credential Loading Priority

Credentials file format

CLI Options

Agent wallets (x402)

Sandbox / demo mode

Building from source

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

AgentValetofficial

Latest Blog Posts

MCP directory API

`vault_entries_list`

`vault_entry_get`

`vault_exec`

`vault_entry_inject_env`

`vault_rsync`

`vault_entry_forget`