wundervault
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WUNDERVAULT_MOCK | No | ||
| WUNDERVAULT_AGENT_KEY | No | ||
| WUNDERVAULT_AGENT_NAME | No | ||
| WUNDERVAULT_AGENT_TOKEN | No | ||
| WUNDERVAULT_AGENT_VAULT_URL | No | ||
| WUNDERVAULT_CREDENTIALS_FILE | No | ||
| WUNDERVAULT_AGENT_VAULT_API_KEY | No |
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 |
|---|---|
| vault_entries_listA | List the vault entries this agent may use. For each: its ID, name, tier, what kind of secret it is — web-service (vault_call), SSH (vault_ssh_exec), wallet (vault_pay) or signing key (vault_sign) — and any signed operations it offers. Never a secret's value — no tool returns one. |
| vault_callA | Call a web service with a vaulted secret that is never returned to you: the broker attaches the secret, sends the request and gives you the answer with the secret removed. Two ways to call. Describe the request yourself with Either way the entry decides how the secret is attached (a header, a query parameter, a username and password, or part of the web address) — you never choose that, and never see the secret. |
| vault_payA | Pay an x402 "402 Payment Required" from a vaulted wallet whose key is never returned to you. Pass the 402 reply's PAYMENT-REQUIRED header (or the decoded JSON, or a v1 402 body) as payment_required; you get back the header to send when you retry the same request. USDC only, on Base, Base Sepolia, Solana and Solana devnet. Payments inside the owner's rules (allowed payees, a daily limit) are signed at once; anything else waits for the owner to approve, and if they have not answered yet, call again with the same payment to keep waiting. |
| vault_signA | Sign data with a vaulted signing key whose value is never returned to you. Every signature is approved by the owner, who is shown the data (in full when it is text up to 64 KiB) and its sha256. Returns the signature (base64), the public key and the algorithm. At most 256 KiB. |
| vault_ssh_execA | Run a command on a remote host, or rsync files to it, using a vaulted SSH key that is never written to disk and never returned to you. The key stays inside the broker, which answers signature requests over a private ssh-agent socket that exists only for the duration of this call. You choose the remote command; you do not get the key. The destination is checked against the ssh_hosts allowlist on the entry, and the ssh command line is constructed here — naming a different host inside remote_argv does not change where it connects. An entry with no ssh_hosts authorises nothing. Every signature is audited with the key fingerprint and the authorised host. |
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 5 tools
Each tool maps to a distinct capability: discovery (vault_entries_list), generic web calls (vault_call), x402 payments (vault_pay), signing (vault_sign), and SSH/rsync (vault_ssh_exec). The only mild overlap is vault_call vs vault_pay, since both issue HTTP requests with a secret attached, but the descriptions clearly separate generic service calls from 402 payment flows.
All tools share a strong 'vault_' namespace prefix and use lowercase snake_case. The one deviation is ordering: vault_entries_list is noun-first while vault_call, vault_pay, vault_sign, and vault_ssh_exec are verb-oriented, but this is minor and still readable.
Five tools is well-scoped for a secrets broker: one discovery tool plus one executor per supported secret type (web-service, wallet, signing key, SSH). No tool feels redundant or padded.
The surface maps cleanly onto the declared secret types enumerated by vault_entries_list, giving lifecycle coverage for discovery and use of each. Minor gaps exist around inspecting an entry's operation schema/args in detail and checking pending owner approvals without re-calling, but agents can work around both.