Skip to main content
Glama
wundervault

wundervault

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
WUNDERVAULT_MOCKNo
WUNDERVAULT_AGENT_KEYNo
WUNDERVAULT_AGENT_NAMENo
WUNDERVAULT_AGENT_TOKENNo
WUNDERVAULT_AGENT_VAULT_URLNo
WUNDERVAULT_CREDENTIALS_FILENo
WUNDERVAULT_AGENT_VAULT_API_KEYNo

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 request (origin, method, path, and optional query, body and your own headers). Or run a named operation the owner defined, with operation_id and typed args: the operation fixes the origin and route, returns only the fields it permits, and is signed with a key derived from the secret itself, so a definition altered in transit is refused. vault_entries_list shows which operations an entry offers.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessLimited data