Skip to main content
Glama
Erseni

vault-ask (Erseni Vault)

by Erseni
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

send_secret

Generate or relay a password, token, or API key, encrypt it locally, and return a one-time link that shows the value once without putting it in chat.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory for relative paths and the command
fileNoAlso write the value into this file (permissions 600)
nameNoName of the value, for example "DB_PASSWORD". Default label on the page, and the variable name for env_file and command
labelNoLabel shown above the value on the page, for example "Database password for app@db.example.com"
lengthNoLength of the generated value, default 32
charsetNoCharacters of the generated value, default alnum
commandNoAlso run this command with the value in the environment variable NAME, for example ["./scripts/set-db-password"]. Its output comes back with the value masked
env_fileNoAlso write NAME=value into this .env file (permissions 600)
from_envNoSend the value of this environment variable of the server process instead of a generated value
from_fileNoSend the content of this file instead of a generated value
ttl_secondsNoHow long the link stays valid, default 86400

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: generation is local, the value is encrypted on this machine, only a one-time link is returned that shows the value once, the value never appears in chat, and the same value is routed to env_file/file/command destinations. It even discloses that command output returns with the value masked.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a dense single paragraph that front-loads the usage trigger and routing rule before the mechanics, which is the right ordering. For an 11-parameter tool this length is justified, though a couple of clauses ('never write one into the chat', 'shows the value once') restate the same security point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description explicitly covers the return shape ('the link, its expiry and the length, never the value'), which is exactly what the agent needs. Combined with the generation/encryption/destination behavior, nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema lacks: the default is 32 letters and digits unless length or charset override it, name is required except for file, and the same value flows to every destination. It does not document every parameter (e.g. cwd, ttl_seconds defaults are left to the schema), keeping it at 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it generates, takes, encrypts and returns a one-time link for a password/token/API key. It is clear about what the tool produces, but it never names or contrasts with its siblings request_secret and run_with_secret, so an agent cannot fully disambiguate from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit trigger ('whenever the user asks you to generate, create or send them a password, token, API key'), concrete examples including a non-English one, and a firm negative rule ('Do not generate a secret any other way and never write one into the chat'). It stops short of naming alternative tools, so it does not reach a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools