keywarden
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KEYWARDEN_HOME | No | Override the vault directory location. | ~/.keywarden |
| KEYWARDEN_PASSPHRASE | No | The passphrase to unlock the vault. Required when using a passphrase-based vault (initialized with `keywarden init --passphrase`). | |
| KEYWARDEN_DISABLE_EXEC | No | Set to '1' to drop the `run` tool entirely and expose only the HTTP proxy. | 0 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_secretsA | List every credential in the vault as metadata only: ref, provider, description, which field names exist, when it was last used. Never returns credential values. Start here. |
| describe_secretB | Metadata for one credential plus how it can be used: whether it can be proxied over HTTP, which hosts it may reach, and which environment variables it maps to when injected. |
| list_providersA | List known provider presets (openai, aws, stripe, ...) with their allowed hosts, expected field names, and env-var mappings. Useful before asking the user to add a new credential. |
| http_requestA | Make an authenticated HTTPS request using a vaulted credential. keywarden attaches the credential itself; you never see it. The destination must be an allowed host for that credential. Redirects are not followed and non-HTTPS is refused. |
| runA | Run a local command with one or more vaulted credentials injected as environment variables (e.g. aws, terraform, gh, psql, a build script). The command is executed directly with no shell, so pass arguments as an array. Output is scanned and any credential appearing in it is masked before you see it. |
| audit_tailA | Recent entries from keywarden's tamper-evident audit log: which credential was used, by which capability, against which host or command, and whether it was allowed or denied. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a clearly distinct concern: auditing, listing all secrets, inspecting one secret, listing provider presets, making an HTTP request, and running a local command. Even http_request and run, which both consume credentials, are clearly separated by remote HTTP vs local execution.
list_secrets, list_providers, and describe_secret follow a readable verb_noun pattern, but audit_tail, http_request, and run break it: audit_tail is noun-first, http_request is a noun phrase, and run is a bare verb. The set is understandable but mixes conventions.
Six tools is a well-scoped size for a credential vault/usage server. Each tool covers a meaningful part of the workflow without redundancy or bloat.
The server covers the core credential-usage workflow well: list, describe, use over HTTP, use locally, and audit past use. Credential creation/update/delete is absent, but the descriptions suggest new credentials may be added by the user outside the tool set, so this is a minor workaround gap rather than a fatal one.