HashiCorp Vault MCP Server

Vault is where a lot of organisations keep the things they most want an agent not to leak, which makes an MCP server for it a deliberate trade: real operational leverage in exchange for pointing a model at your secrets store. HashiCorp ships this one themselves, in Go, under MPL-2.0.

What it exposes

Mount management — create_mount, list_mounts, delete_mount, so an agent can see and shape the secret engines a Vault instance runs.

Key-value secrets — list_secrets, read_secret, write_secret, delete_secret, covering both whole secrets and individual keys within them.

PKI — the largest group, and the one that saves the most time: enable_pki, create_pki_issuer, list_pki_issuers, read_pki_issuer, create_pki_role, read_pki_role, list_pki_roles, delete_pki_role and issue_pki_certificate. Standing up an internal CA and issuing a certificate against a role is normally a sequence of carefully ordered CLI calls; here it is a request.

Running it

It is distributed as a Go binary and as the hashicorp/vault-mcp-server Docker image, and speaks both stdio and HTTP transports. Configuration is three environment variables: VAULT_ADDR (defaults to http://127.0.0.1:8200), VAULT_TOKEN (required), and VAULT_NAMESPACE for Vault Enterprise. VS Code and Claude Desktop configs typically run the Docker image and prompt for the token rather than storing it in a config file — worth copying, because a Vault token in a plaintext JSON file undoes much of the point of Vault.

Worth knowing

HashiCorp's own documentation is explicit that the server is intended for local use, and cautions that model-generated outputs vary and should be reviewed against your security and compliance requirements before you act on them. Treat it as a tool for development and operator workflows against a Vault you control, scope the token narrowly, and do not point it at production secrets on the assumption that a read tool will stay a read tool — write_secret and delete_mount are in the same tool list.