Connect Claude to HashiCorp Vault

Describe the token this connection is using - its display name, the policies attached to it, when it was issued, when it expires, whether it is renewable and which auth path minted it. Every valid Vault token can make this call whatever its policy, which is why it is the health check: it proves the address and the token together without needing any particular permission. Vault returns the token itself in the response; that key is stripped inside the gateway before anything sees it, and the rest of the answer is not written to the audit log either. Read it first when a call is refused - the `policies` list is usually the explanation.

List the secret engines mounted on this cluster, keyed by their mount path - kv/, database/, pki/, transit/ and so on - with each one's type, description, options and lease settings. Call it first: every secrets operation here needs a mount path, and for a KV engine the `options.version` field is what says whether it is v1 or v2. Only v2 mounts have the metadata paths list_secrets and read_secret_metadata read. This returns configuration, not contents.

List the secret names under one path in a KV v2 engine. It reads the engine's `metadata` path, so it returns keys and nothing else - a name ending in a slash is a folder to descend into, a name without one is a secret. This is the map of where secrets live, and it is the operation to reach for when the question is "what is stored under apps/billing". It does not recurse: call it again for each folder. Nothing here can read what any of these names holds. A nested folder is written with ordinary slashes here - apps/billing - and reaches Vault percent-encoded, which is how a path can never walk up out of the metadata endpoint.

Read one secret's metadata: when it was created and last updated, how many versions exist, which of them are deleted or destroyed, the configured maximum version count, and any custom metadata attached to it. This is how to answer "when was this credential last rotated" and "is anything still reading the old version" without reading the credential. It reads the engine's `metadata` path; the sibling `data` path that would return the value is not reachable from this connector at all. Write the path with ordinary slashes; it is sent percent-encoded, so no value of secret_path can address the sibling data endpoint.

List the names of the ACL policies configured on this cluster. Policies are how Vault decides who may reach which path, so this plus read_policy is the answer to "who can read production database credentials". Names only - read_policy returns what each one actually grants.

Read one ACL policy document by name. The document is HCL naming paths and the capabilities granted on each - create, read, update, delete, list, sudo, deny. It says what a holder of the policy may do; it holds no secret of its own. Use it to audit whether a policy reaches further than intended, particularly whether anything grants read on a KV `data` path it should not.

List the auth methods enabled on this cluster, keyed by their mount path - token/, userpass/, oidc/, approle/, kubernetes/ and so on - with each one's type, description and default lease settings. This is how people and machines get a token in the first place, so it is the second half of the access map that list_policies starts. Configuration only: no credential belonging to any method is returned.

List the child namespaces under the current one. Vault Enterprise only - an open-source cluster answers 404 here, which is the expected result and not a broken install. Namespaces are how one cluster is divided between teams, and each has its own mounts, policies and tokens, so a path that exists in one does not exist in another. Set the namespace credential on the connection to work inside a particular one.

List the lease ids outstanding under one prefix - the dynamic credentials Vault has issued and not yet expired, such as database logins minted by the database engine. Ids only: this returns which leases exist, never the credentials behind them, and this connector has no operation that looks one up or revokes one. Prefixes look like database/creds/readonly or auth/token/create. This endpoint requires the `sudo` capability on sys/leases/lookup, so a deliberately narrow token will be refused here and that is a reasonable outcome rather than a misconfiguration. Prefixes are written with ordinary slashes and sent percent-encoded.

Report the cluster's health: whether it is initialised, sealed, a standby or a performance standby, its version, cluster name and replication mode. Vault normally signals these states through the HTTP status code rather than the body - 429 for standby, 503 for sealed, 501 for uninitialised - which would surface here as a failed call rather than an answer, so this operation asks Vault to return 200 for every one of them and report the state in the body instead. Read it before concluding a cluster is down.

Report the seal state in detail: whether the cluster is sealed, how many unseal key shares its threshold requires and how many have been supplied, the seal type, the storage type and the version. A sealed Vault answers every other call in this connector with an error, so this is the operation that explains why. It cannot unseal anything - this connector has no writes at all.