HashiCorp Vault

HashiCorp Vault MCP Server provides a complete MCP integration that lets you manage Vault secrets and policies through a safe, auditable interface. It bridges Vault’s security model with the structured interaction model MCP expects, enabling automated secret rotation, policy authoring, and discovery from MCP-aware clients while keeping raw Vault APIs hidden from end users.

How to use

You connect an MCP client to the Vault MCP Server over stdio or via a remote MCP endpoint. Once connected, you can call typed tools to write, read, or delete secrets, or to create policies. You can browse resources like vault://secrets and vault://policies to discover what you can manage, and you can use prompt handlers to synthesize Vault-ready policies from natural-language intents. Every operation is explicit and scoped to the token you provide, so you control exactly what the server can do.

How to install

Prerequisites you need before starting: Docker 24+ and a running Vault instance with the KV v2 secrets engine enabled. You also need a Vault token that starts with hvs. and has the necessary capabilities for your tasks (read, write, delete, and policy management). If you want secure TLS in testing, provide proper CA certificates or disable TLS checks only for testing purposes.

Install the server using the provided MCP configurations for your environment. Below are example MCP configurations you can place in your MCP client setup. Use the exact blocks shown when configuring your client to connect to the Vault MCP Server.

{
  "mcpServers": {
    "Vault": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "VAULT_ADDR=https://your-vault-server:8200",
        "-e",
        "VAULT_TOKEN=hvs.your-vault-token",
        "ashgw/vault-mcp:latest"
      ]
    }
  }
}

If you prefer running the server locally via Docker with a host network, use the following configuration snippet in your client setup.

{
  "mcpServers": {
    "Vault": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--network=host",
        "-e",
        "VAULT_ADDR=http://127.0.0.1:8200",
        "-e",
        "VAULT_TOKEN=hvs.test-token-1234567890abcdef",
        "vault-mcp:local"
      ]
    }
  }
}

Additional configuration notes

Configure Vault-related environment variables in your MCP client setup as needed. The core variables shown here are VAULT_ADDR and VAULT_TOKEN. You can also pass TOR/CA settings if your environment requires them.

If you are debugging TLS issues, remember to set NODE_TLS_REJECT_UNAUTHORIZED to 0 only for testing. Prefer proper CA bundles in production.

Configuration

Environment variables you use to run the Vault MCP Server include VAULT_ADDR and VAULT_TOKEN. You can pass additional Vault-related variables as needed by your deployment, such as VAULT_NAMESPACE for multi-tenant Vault setups. The server forwards these environment variables to the Vault client library.

Tool Reference

The MCP server exposes a set of tools that map directly to Vault operations. Payloads are validated before being sent to Vault, and responses mirror Vault’s JSON structure.

• create_secret: Write or update a secret at a KV v2 path. Provide path and data to store secret values. Returns Vault write metadata.

• read_secret: Retrieve a specific secret version from KV v2. Provide path and optional version. Returns the secret data and metadata.

• delete_secret: Soft-delete the latest version of a KV v2 secret. Provide path. Returns deletion metadata.

• create_policy: Create or replace a Vault ACL policy. Provide name and policy string in HCL. Returns a success indicator.

Resource Reference

Browse data with resource endpoints to help you decide which tool to call next.

• vault://secrets lists keys at the root of the KV store. Nested directories end with / to aid drilling down.

• vault://policies enumerates policy names the token can read, useful for auditing or guiding prompts.

Prompt Reference

Prompts help turn structured input into Vault-ready output. Use prompts to generate policy drafts or to map an intent to a set of capabilities across paths.

• generate_policy: Produce a policy draft by mapping a path and capabilities to a JSON object that associates paths with capability arrays.

Troubleshooting

Authentication failed: Ensure VAULT_TOKEN is valid and has the needed policies. Check token TTL and bindings with a token lookup.

Permission errors: Update your Vault policy to grant the required capabilities (read, list, create, update, delete, sudo as needed) on the target paths.

TLS or certificate issues: Use a proper CA bundle or set NODE_TLS_REJECT_UNAUTHORIZED=0 only for testing. Prefer proper TLS configuration in production.

Empty resources: The token can only list paths it has permission to access. Review policies to ensure the necessary list capabilities are present.

License

Distributed under the MIT License.

Available tools

create_secret

Write or update a secret at a KV v2 path. Provide a path and a data object containing key/value pairs to store under data.

read_secret

Read a secret from KV v2 by path and optional version. Returns the secret data and metadata.

delete_secret

Soft-delete the latest version of a KV v2 secret at the given path, preserving older versions unless destroyed.

create_policy

Create or replace a Vault ACL policy by supplying a name and an HCL policy string.

generate_policy

Create a Vault-ready policy draft by specifying a target path pattern and a set of desired capabilities; returns a mapping of paths to capabilities.