vault-ask (Erseni Vault)
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAULT_ASK_SERVER | No | Optional Vault server URL, default https://vault.erseni.com | |
| VAULT_ASK_API_KEY | No | Optional Erseni Vault API key. Without it, each request is paid with a small proof of work. |
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 |
|---|---|
| request_secretA | Use this whenever you need a password, token, API key or other secret from the user, for example "I will give you my database password" or "you need my API key for X". Never ask the user to type or paste a secret into the chat. Asks the user for one or more secrets and writes them into a .env file or a file, without the values ever passing through this conversation. First call without request_id: returns a link. Show it to the user, then call again with the returned request_id; that call waits for the answer and writes the file with permissions 600. The result only contains names and lengths, never a value. |
| run_with_secretA | Use this whenever a single command needs a password, token, API key or other secret from the user, for example "connect to the database with my password" or "deploy with my API token". Never ask the user to type or paste a secret into the chat. Asks the user for one or more secrets and runs exactly one command with them as environment variables. The user sees the command before entering anything, and only this command can receive the values. First call without request_id: returns a link. Show it to the user, then call again with the returned request_id; that call waits for the answer, runs the command and returns its exit code and its output with every value masked. |
| send_secretA | Use this whenever the user asks you to generate, create or send them a password, token, API key or other secret, for example "generate a password for my database", "generier mir ein Passwort" or "send me the key". Do not generate a secret any other way and never write one into the chat. Generates the value locally (32 letters and digits unless length or charset say otherwise) or takes it from from_file or from_env, encrypts it on this machine and returns only a one-time link that shows the value once in the browser. Give the user that link. With env_file, file or command the same value also goes to that destination (needs name except for file), so the system and the link hold the same value. The result contains the link, its expiry and the length, never the value. |
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 3 tools
The three tools split along a clear axis: request_secret pulls secrets inbound into a file, run_with_secret uses a secret to execute one command, and send_secret generates/returns a secret outbound. request_secret and run_with_secret share the same ask-the-user/link flow and could momentarily be confused, but their end outcomes (write a file vs. run a command) are clearly spelled out.
All three follow a strict verb_secret pattern (request_secret, run_with_secret, send_secret). The verb meaning is consistent: the action describes what happens to the secret (request in, run with, send out).
Three tools is on the lean side but each covers a genuinely distinct secret lifecycle stage (acquire, use, issue). The set feels deliberately minimal rather than padded, which suits a security-sensitive vault.
Inbound acquisition, command usage, and outbound distribution with multiple destinations (file, env_file, command) are all covered, giving a coherent lifecycle. Minor gaps: no explicit tool for listing, rotating, or revoking previously stored secrets, though these could be handled outside the surface.