LABSCO SUMMARY
The author tells you where not to use it.
Since HashiCorp shipped an official server, this one dropped formal releases, versioning and a changelog, and the README says plainly that it is not recommended for enterprise production. What it still offers is local execution as a container against your own cluster, a wider reach than a read-only view, and the diagnostic prompt that audits a Vault configuration and reports what looks wrong. Treat it as a lab and troubleshooting tool that holds real credentials, and scope the auth role accordingly.
What it is
An independent Vault server that can run locally as a container image rather than only remotely. It reaches across the system backend — ACL policies, audit devices, authentication engines, Raft clustering and snapshots, secrets engines — and into the secrets backends for KV Version 2, PKI, Transit, Identity/Alias and Database. HashiCorp now publishes an official Vault MCP server; the author states this one keeps being maintained but does not try to compete with it.
What you get
- Tools (138) across the system backend and the Secrets backend — KV Version 2, PKI, Transit, Identity/Alias and Database
- Resources (5) reporting current ACL policies, audit devices, authentication engines, secret engines and Raft cluster configuration
mcp.vault.generate-smart-acl-policyruns an interactive workflow that builds and optimises a policy from your requirementsmcp.vault.diagnose-vault-statescans your cluster and reports where the configuration falls shortmcp.vault.example-acl-policyandmcp.vault.generate-acl-policyreturn policy JSON you can edit and feed back as tool input
Requirements
Docker, running matthewschuchard/vault-mcp-server over stdio, or the vault-mcp-server package. Point it at your cluster with VAULT_URL, which defaults to http://127.0.0.1:8200. VAULT_AUTH_METHOD picks between approle, jwt, token and userpass, and the matching variables follow — VAULT_TOKEN, VAULT_ROLE_ID and VAULT_SECRET_ID, VAULT_USERNAME and VAULT_PASSWORD, or VAULT_JWT and VAULT_ROLE. VAULT_NAMESPACE is enterprise-only and CACHE_TTL defaults to 60, which is how long reads and lists are served from cache.
Setup effort
One command plus a key — docker run -i --rm -e VAULT_TOKEN -e VAULT_URL matthewschuchard/vault-mcp-server
USE CASES
01
Auditing how a Vault cluster is set up
Read back enabled ACL policies, audit devices, auth engines and secret engines, then run the state scan.
02
Writing an ACL policy without hand-rolling the JSON
Work through the interactive policy builder, then submit the result as tool input.
03
Working with KV, PKI and Transit from a conversation
Read and manage secrets, certificates and encryption keys against the engines you have enabled.
04
Checking Raft cluster health and snapshots
Pull the current Raft cluster configuration and manage storage snapshots.
BEFORE YOU INSTALL
What to know first
Requires
- docker on PATH
- A Vault token (VAULT_TOKEN) and your Vault address (VAULT_URL), or the variables for another auth method
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
docker run -i --rm -e VAULT_TOKEN -e VAULT_URL matthewschuchard/vault-mcp-serverMCP Clients
Claude Desktop
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"vault": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"VAULT_TOKEN",
"-e",
"VAULT_URL",
"matthewschuchard/vault-mcp-server"
],
"env": {
"VAULT_TOKEN": "<YOUR_VAULT_TOKEN>",
"VAULT_URL": "<YOUR_VAULT_URL>"
}
}
}
}The server reads its settings from environment variables, each named in a -e argument: VAULT_TOKEN and VAULT_URL (your Vault address; default http://127.0.0.1:8200) for token sign-in. Run from a terminal, docker takes their values from your shell; in the client blocks they sit under env. Other settings (VAULT_AUTH_METHOD, VAULT_NAMESPACE, approle or userpass credentials) are added the same way.
VS Code
VS CODE · JSON
{
"servers": {
"vault": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"VAULT_TOKEN",
"-e",
"VAULT_URL",
"matthewschuchard/vault-mcp-server"
],
"env": {
"VAULT_TOKEN": "<YOUR_VAULT_TOKEN>",
"VAULT_URL": "<YOUR_VAULT_URL>"
}
}
}
}The server reads its settings from environment variables, each named in a -e argument: VAULT_TOKEN and VAULT_URL (your Vault address; default http://127.0.0.1:8200) for token sign-in. Run from a terminal, docker takes their values from your shell; in the client blocks they sit under env. Other settings (VAULT_AUTH_METHOD, VAULT_NAMESPACE, approle or userpass credentials) are added the same way.