Veil lets an agent coordinate secure credential storage without ever receiving the credential value.
Request that a user store a credential in an allowed destination such as an env file, GCP Secret Manager, or Firestore.
Poll a credential request for non-sensitive status, optionally waiting briefly.
Cancel a pending request, destroying any credential already entered.
Revise a request by canceling it and creating a corrected replacement that requires fresh authorization.
List available destinations and the target fields each destination expects.
Integrates with Google Cloud Secret Manager and Firestore to securely store credentials. Supports creating, updating, and replacing secrets in Secret Manager, and storing secrets in Firestore (with warnings about high-risk operations).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Veil store my Stripe production API key in Google Secret Manager"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Let your AI agent set up API keys without ever seeing them.
You ask Claude, Cursor or any MCP client to "put the Stripe key in our .env" — or in Secret Manager, Vercel, your own API. The agent describes where it goes. You read that in Lockbox's own window and paste the value there. The key goes straight to the destination and never enters the chat, the prompt or the logs.
The agent describes the destination. A file, a program such as gcloud, or an HTTPS
request, with {{secret}} where the value goes. The tool has no field that could carry a
value.
You check and paste. Lockbox's local window shows where the key goes in one line, warns about anything new or odd, and checks the key's format. The exact request is one click away.
Lockbox sends it. The agent only learns STORED and a reference. It never sees the key.
claude mcp add lockbox -e LOCKBOX_ENV_ALLOWED_ROOTS="$PWD" -- npx -y lockbox-mcp serveThen ask your agent: "store my Stripe test key in .env".
Lockbox is a stdio MCP server, so you do not run it yourself — your MCP client starts it, the same way it starts any other npm-published server. Requires Node 20+.
cd ~/some/project
claude mcp add lockbox -e LOCKBOX_ENV_ALLOWED_ROOTS="$PWD" -- npx -y lockbox-mcp serveAdd -s project to record it in the repository's .mcp.json instead of your own config.
Drop this into the client's MCP configuration — the mcpServers block is the same shape
everywhere:
{
"mcpServers": {
"lockbox": {
"command": "npx",
"args": ["-y", "lockbox-mcp", "serve"],
"env": {
"LOCKBOX_ENV_ALLOWED_ROOTS": "/absolute/path/to/your/project"
}
}
}
}Prefer a pinned install to an ephemeral one:
npm install -g lockbox-mcp
# then use `lockbox-mcp serve` as the command, with no npxThe package is published to npm, unscoped, as lockbox-mcp.
Set LOCKBOX_ENV_ALLOWED_ROOTS. File destinations refuse to write outside those
directories, and they default only to the server's working directory. Everything else is
optional — see Configuration.
Destinations behind a login (Google Secret Manager, Vercel, GitHub) are reached through their
own CLI, which uses the login you already have — gcloud, vercel, gh. See
Destinations.
Ask your agent for something like "store my Stripe test key in .env". Lockbox opens its window on your machine; the agent does not receive that link. The band at the top tells you the environment at a glance, and the field tells you whether the key looks right before you send it.
Enter continues and Esc cancels. The link works once: if anything opened it before your browser did, Lockbox shows an alarm and a Cancel button instead of the request. Lockbox's stderr carries structured audit JSON; nothing else is expected of you in the terminal.
Related MCP server: Janee
It removes an entire class of failures caused by the agent knowing the secret. With Lockbox in the loop, a credential does not pass through:
LLM prompts or conversation history
MCP tool arguments or tool results
agent memory or generated code
shell command arguments or process argv
logs, debug traces or telemetry
URLs
model-visible command output
Lockbox does not make an AI agent trustworthy, and it is not "safe AI". It does not guarantee that the agent picked the right destination, that it understood you, that it is free of prompt injection, that the destination is itself secure, that your machine is uncompromised, or that a credential cannot be misused later by software that legitimately receives it.
There are two separate problems here:
Question | Lockbox's answer |
Should the agent know the secret? | No. |
Should the agent decide alone where the secret goes? | Not without human authorization. |
Lockbox answers those two. It does not claim to answer the rest.
Trusted with the credential value:
The human at the keyboard
Lockbox's secure input UI (loopback only, in your control)
Lockbox's secure input broker (this process)
The destination you approved (a file, a program, an HTTPS endpoint)
NOT trusted with the credential value:
The LLM
The agent / MCP client
The conversation
The prompt and any repository content it read
Generated code
Logs, telemetry, crash reportsLockbox's runtime dependency list is one package (zod, for input validation). The MCP
protocol is implemented in-tree rather than through the official SDK, which would add ~90
packages — including HTTP servers and an OAuth stack — to a process that holds plaintext
credentials.
This diagram does not claim the trusted components are invulnerable. It says where the credential is allowed to exist. Lockbox is security-sensitive software: if Lockbox itself is malicious or compromised, the boundary is gone. Its source, dependencies and releases deserve the scrutiny you would give any credential-handling tool.
The secret flow — the human's path, which the model cannot observe:
Human ─▶ Lockbox secure UI (127.0.0.1) ─▶ Broker ─▶ approved definition ─▶ DestinationThe agent flow — everything the model sees:
LLM ─▶ MCP client ─▶ Lockbox MCP server ─▶ non-sensitive result metadataThe MCP tool schema has no property capable of carrying a credential. That is structural,
not a prompt instruction: there is no value, secret_value, password, token,
content or raw_secret field to abuse, closed schemas reject unknown properties, and
arguments are screened for credential-shaped values before they are parsed.
{
"destination": "custom",
"name": "STRIPE_SECRET_KEY",
"target": {
"definition": {
"kind": "command",
"label": "Google Secret Manager",
"executable": "/opt/homebrew/bin/gcloud",
"args": ["secrets", "versions", "add", "stripe-secret-key",
"--project", "acme-prod", "--data-file=-"],
"stdin": "{{secret}}"
}
},
"environment": "production",
"description": "Stripe production API key"
}Lockbox replies with a request_id, a risk classification and the normalized destination —
and opens its own authorization window on your machine. The agent polls secret_status.
destination: "saved:<name>" reuses a destination the human saved earlier.
The agent does not get the authorization link. That link is a capability: anything
holding it can complete the human's half of the flow, and an agent with a shell or an HTTP
tool is precisely the threat model. Lockbox hands it straight to your browser. Set
LOCKBOX_DISCLOSE_AUTHORIZATION_URL=true if your setup needs the agent to relay the link (for
example, a remote or headless session) — and understand that this lets a compromised agent
authorize its own request.
The link works once. Opening it trades it for an HttpOnly; SameSite=Lax session cookie
scoped to that request and redirects to an address with no token in it; every later page and
form needs the cookie. A second opening of the same link gets an alarm page ("This link was
already opened") with a Cancel button, never the request. So a copy left in browser history,
a process list or a log is dead once you open it, and one used by someone else first is
visible to you.
Logs never hold the identity phrase, and hold the link only as a last resort. MCP hosts
save server stderr to files any process running as you can read (Claude Desktop under
~/Library/Logs/Claude/, Claude Code under its cache directory), so the audit record carries
a short fingerprint of the link instead. The full link is logged only when no browser could
be opened (LOCKBOX_OPEN_BROWSER=false, too many windows, or the opener failed), because the
operator then has no other way in.
Tool | Purpose |
| Create a credential request. Returns non-sensitive metadata and a request id. |
| Poll a request. Never returns credential material. |
| Cancel a pending request; any entered value is destroyed. |
| Invalidate an authorization and start a new one. Nothing is edited in place. |
| The definition contract, worked examples, and the user's saved destinations. |
Stage A shows the credential name and one destination line — the definition's label and
its host, program or file — plus a line for anything worth a second look: a host never
used before, a host spelled with non-ASCII characters, an IP address instead of a name, a
program outside the system folders, a saved destination that changed. The full request (the
URL, every header and the body; or the program, each argument and stdin; or the file and
its content) sits behind "See exactly what will be sent", closed by default, with the
canonical JSON and its hash. Every custom destination needs a second confirmation in Stage
B, after entry and before anything is sent: the human types the host, the program name or
the file (.env:API_TOKEN for a variable), and the server checks it. This is an attention
check, not authentication: the expected text is on the page. What keeps a second party out
of Stage B is the session cookie. The value is never displayed back.
POSTs are refused unless they come from Lockbox's own page (Origin and Sec-Fetch-Site), and
every response sets Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy to
same-origin. The credential field asks browser and third-party password managers not to
save it.
The page runs one inline script under a per-response CSP nonce. It describes the value's
shape (length, a live/test marker against the destination's environment, stray
whitespace), counts down the expiry and maps Esc to Cancel. The CSP gives it no
network access, and Cancel is a separate form, so cancelling never sends the value. Without
JavaScript the page still works, minus those three aids.
The page the human reads and the operation the executor performs are the same immutable object — there is no separate "display destination". Any change to destination, project, secret name, operation, write mode or adapter invalidates the authorization and requires a new one.
There are no built-in destinations. The agent writes a definition — JSON with
{{secret}} exactly once where the value goes, and optionally {{name}} for the credential
name — and the human approves it as rendered. Three kinds:
Kind | What it does | Rules |
| Writes a local file. Mode | Inside |
| Runs a program with fixed arguments and hands it the value on stdin. | Absolute path, pinned by real path and SHA-256 at approval and re-checked before it runs; no shell; minimal environment; |
| Sends one HTTPS request. |
|
// A .env variable
{ "kind": "file", "label": "Project .env", "path": ".env",
"template": "{{name}}={{secret}}", "mode": "env" }
// Google Secret Manager, through gcloud's own login
{ "kind": "command", "label": "Google Secret Manager", "executable": "/opt/homebrew/bin/gcloud",
"args": ["secrets", "versions", "add", "stripe-secret-key", "--project", "acme-prod", "--data-file=-"],
"stdin": "{{secret}}" }
// An HTTPS API that needs no other token
{ "kind": "http", "label": "Internal secrets API",
"url": "https://secrets.example.com/v1/projects/acme/secrets", "method": "POST",
"headers": { "Content-Type": "application/json" },
"body": { "type": "json", "value": { "name": "{{name}}", "value": "{{secret}}" } },
"reference": "$.id" }Saved destinations. At Stage B the human can tick Save as a trusted destination and
name it; it is saved only if the write succeeds. Next time the agent asks for
saved:<name>, and the window reads "Saved · name · host". Each entry is pinned to the
SHA-256 of its canonical JSON: if the file is edited, the window says Changed since you saved
it and reviews it as new. The store lives at $XDG_CONFIG_HOME/lockbox/destinations.json
(mode 0600), written only by Lockbox; the window can forget an entry.
What is not covered yet. An HTTPS API that needs its own token besides the credential (Vercel, GitHub, Doppler REST) is reached through its CLI instead: the agent cannot supply that token, and Lockbox does not ask for two values in one request. Firestore has no CLI that writes a single field cleanly, so it has no recipe today.
Stated plainly, because a security tool that oversells itself is worse than none:
The broker process sees the secret. That is the point: something must, or storage is impossible. The guarantee is that only the minimal trusted transport and destination components do.
Memory erasure is best-effort. SecretBuffer wipes the exact Buffer it owns, and
the HTTP body is percent-decoded into buffers Lockbox wipes too. But any conversion to a
JavaScript string — which writing a .env line requires — creates an immutable copy that
V8 may keep until garbage collection, and that copy cannot be wiped. Lockbox minimizes those
conversions rather than pretending they do not happen.
The UI is loopback HTTP. Any process running as your user on your machine can reach it, and any such process could also imitate it. Lockbox refuses to bind anywhere but loopback. Request pages show a per-process identity phrase, but it is no longer logged, so today there is no second channel to compare it against: treat it as decoration, not as anti-spoofing. Withholding the link and making it single-use raise the bar; they do not stop a process that wins the race to the link, reads the browser's memory, or binds its own lookalike port.
An agent with an unrestricted shell is out of reach. Running as you, it can read
files Lockbox writes (including a .env destination), browser state and MCP logs. No page
design fixes that. Run the agent sandboxed — for example Claude Code's sandboxed Bash,
with loopback and the MCP log directories outside what it may reach.
Lockbox sends where you approved, not where it is wise to. An agent writes the definition, so a hijacked agent can propose an attacker's endpoint. Lockbox shows the host first, flags it when it is new or disguised, and makes you type it — but a human who approves what they did not read has approved it.
A definition is only as safe as what it runs. A command destination runs the
program you approved with the value on stdin; what that program then does with it is
outside Lockbox.
Timeouts are enforced by Lockbox. HTTP requests and commands are cut off at
LOCKBOX_ADAPTER_TIMEOUT_SECONDS, and a command is killed with SIGKILL.
Preflight is best-effort. A provider that is unreachable at preflight is reported as unavailable rather than guessed at.
Crash semantics. A crash between the provider write and the response can leave a credential written with no local record of success. Lockbox reports the request as failed; the destination is the source of truth.
git clone https://github.com/rosostolato/lockbox-mcp && cd lockbox-mcp
npm install
npm run check # typecheck + lint + format + tests
npm run buildTo point a client at your checkout, use node /path/to/lockbox-mcp/dist/index.js as the
command instead of npx.
Configuration is read from Lockbox's own environment — never from tool arguments, so an agent cannot relax a policy:
Variable | Default | Meaning |
|
| Request expiry. |
|
| Upper bound on one destination write. |
|
| Require confirmation for medium-risk operations. |
|
| Secure UI bind address. Loopback only; anything else refuses to start. |
|
| Open the authorization window automatically. |
|
| Return the authorization link to the agent. |
| current directory | Roots |
|
| Permit writing into a git-tracked, or new and un-ignored, file. |
|
| Permit file names other than |
|
|
|
|
| Kinds an agent may define. |
| any | Comma-separated allowlist of HTTPS hosts; empty means any host, still reviewed. |
|
| Permit hosts that resolve to loopback, private or link-local addresses. |
|
| Where saved destinations live. |
npm test # everything
npm run test:security # the adversarial suite only
npm run check # what CI runsThe security suite is a product requirement, not a nicety. It contains canary-leakage
detection across every observable channel, malicious-agent tests, prompt-injection
fixtures, TOCTOU and replay tests, 100-way concurrency stress, race conditions, crash
paths (including a real SIGKILL mid-write), provider-failure simulation, UI checks and
fuzzing. A release is blocked if any canary leaks, any authorization bypass succeeds, any
post-approval mutation succeeds, any completed request is replayable, any secret crosses a
request boundary, any raw provider error reaches MCP, or any high-risk operation skips
confirmation.
See docs/SECURITY_MODEL.md for the invariant-to-test map.
Version 0.1.0, built to SPEC.md, which stays in the repository as the
authoritative description of the intended behaviour. The implementation is TypeScript on
Node; it was ported from an equivalent Python implementation, which remains in the git
history. Every substantial module and test
cites the section it implements, so a reviewer can check the code against the requirement
rather than against a summary of it.
The MVP is complete and the full suite — including the adversarial one — passes. What remains before anyone should rely on it in anger: independent review, human-factor testing of the confirmation UI (SPEC.md §35), and signed release artefacts (§43).
Security is the product here, so the bar for changes is specific rather than bureaucratic:
A change that touches credential handling, authorization or the MCP surface needs a test that attempts to break the invariant it affects, not only one that shows it working.
Never weaken a security test to make a suite pass. If a test reveals an architectural flaw, the architecture is what changes.
New runtime dependencies in the core are opposed by default. The broker is the trusted computing base for credential material; provider SDKs belong behind an optional extra.
Run npm run check before opening a pull request.
Found a vulnerability? Please report it privately through GitHub's security advisories rather than opening a public issue.
Apache License 2.0 © 2026 Eduardo Rosostolato.
Cancel a pending request. Any credential already entered is destroyed.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses a critical side effect: 'Any credential already entered is destroyed.' This is valuable transparency for a destructive mutation. However, it doesn't mention other effects like whether cancellation is reversible or requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, highly concise, and front-loaded with the core action ('Cancel a pending request') followed by a key consequence. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description doesn't explain return values or error conditions. While it covers the key destructive behavior, it lacks guidance on when to use the reason parameter, potential side effects beyond credential destruction, and any prerequisites. For a security-related tool, more context would be helpful, but the essential purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the parameters at all. It doesn't mention that request_id is required or that reason is optional. The schema itself provides clear names, but the description adds no additional meaning, leaving the agent to infer that request_id identifies the request and reason is for audit context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel a pending request' which is a specific verb (cancel) and resource (request). It distinguishes from siblings like secret.store and secret.revise, as it focuses on cancellation and the destruction of already-entered credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pending requests ('Cancel a pending request') but gives no explicit guidance on when to use it versus alternatives, nor exclusions. It lacks context like 'use secret.revise to modify instead' or 'do not use for completed requests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the destinations this Veil instance can write to, with the target fields each one expects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, and the description does not contradict it. It adds context about the content (target fields) which is useful for the agent. Given the annotation already covers safety, the description provides adequate extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description fully explains what it does and includes the key detail about target fields, which is likely sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameterswing schema coverage is 100% (vacuously). Baseline for 0 params is 4, and the description clarifies that the output includes target fields per destination, which adds contextual meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the specific resource (destinations this Veil instance can write to), and adds the detail about target fields. It distinguishes itself from sibling tools like store, cancel, revise, which involve mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to discover available destinations and their required fields), but does not explicitly contrast with alternatives. Since it's a simple listing tool, the purpose clarity implicitly covers usage, though no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a pending request and create a new one. The original authorization is invalidated and the human must authorize the new operation from scratch; an authorized operation can never be edited in place.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Logical name of the credential, e.g. STRIPE_SECRET_KEY. This is a label, never the credential value. | |
| target | Yes | Where the credential goes. Fields depend on the destination; call secret.destinations for the exact contract. | |
| request_id | Yes | ||
| write_mode | No | create | |
| description | No | Short human-readable purpose, shown to the user. | |
| destination | Yes | Which destination adapter should receive the credential. | |
| environment | No | Environment you believe this destination belongs to. Advisory only: Veil classifies the destination itself and uses the stricter of the two. |
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. It discloses that the original authorization is invalidated, the human must reauthorize from scratch, and authorized operations cannot be edited in place. This covers the key side effects and workflow consequences of a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core action, and the second provides the key behavioral consequence and an important invariant. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with nested objects and no output schema, the description explains the compound nature and authorization consequences sufficiently. It could additionally mention that all parameters must be resubmitted for the new request, but the schema and existing wording make the required inputs inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so most parameters have descriptions already. The tool description adds context around request_id by referring to 'pending request' and 'new operation from scratch,' but it does not explain parameter interactions or destination-specific requirements beyond what the schema provides. This is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a compound operation: 'Cancel a pending request and create a new one.' The title, 'Replace a credential request with a corrected one,' further specifies the resource and intent, distinguishing this from sibling tools like secret.cancel and secret.store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: when a pending request must be corrected, and specifically notes that 'an authorized operation can never be edited in place.' It doesn't explicitly contrast with secret.cancel or secret.store, but the described workflow makes the intended use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the non-sensitive status of a credential request. Never returns credential material.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| wait_seconds | No | Optionally block until the request reaches a terminal state or this many seconds elapse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the readOnlyHint annotation by guaranteeing that no credential material is ever returned. This safety guarantee is a key trait not covered by annotations, though it does not disclose blocking behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and add a critical safety note. There is no unnecessary detail or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and a read-only annotation, but the description omits key behavioral details such as the optional blocking behavior via wait_seconds and what the response actually contains (e.g., status list, error scenarios). Without an output schema, the description should describe the return value format more fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters. request_id is self-explanatory from its name, but wait_seconds is already described in the schema. With only 50% schema description coverage, the description fails to compensate for the missing request_id semantics or clarify how to obtain such an ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the status of a credential request and explicitly mentions it never returns credential material. This distinguishes it from siblings like secret.cancel or secret.store, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status but provides no explicit guidance on when to use it versus alternatives. There is no mention of 'use when you need to check status' or exclusions like 'do not use to cancel requests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the human to provide a credential and have Veil write it to the destination described here. The credential value is never passed through this tool, never returned by it, and never becomes visible to the model: the user enters it in Veil's own trusted window. Share the returned authorization_url with the user, then poll secret.status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Logical name of the credential, e.g. STRIPE_SECRET_KEY. This is a label, never the credential value. | |
| target | Yes | Where the credential goes. Fields depend on the destination; call secret.destinations for the exact contract. | |
| write_mode | No | create | |
| description | No | Short human-readable purpose, shown to the user. | |
| destination | Yes | Which destination adapter should receive the credential. | |
| environment | No | Environment you believe this destination belongs to. Advisory only: Veil classifies the destination itself and uses the stricter of the two. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that the credential value never passes through the tool, is never returned, and never becomes visible to the model—a key behavioral trait. It also outlines the multi-step process involving an authorization_url and polling. Annotations already signal destructive and open-world behavior, and the description complements these without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes essential security and workflow context. Every sentence earns its place, and there is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested target, multiple destinations, write modes, environment), the description covers the critical workflow and security aspects, and points to secret.destinations for detailed contracts. It does not explain write_mode or environment semantics, but those are well-documented in the schema. Overall, it is reasonably complete for a tool of this intricacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not directly elaborate on any input parameters, but the schema provides extensive descriptions for 83% of fields. It directs users to secret.destinations for the target contract, which covers the remaining nuance. Since the schema already carries the semantic load, the description adds little beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: asking the human for a credential and having Veil write it to a specified destination. It distinguishes itself from siblings like secret.status and secret.cancel by focusing on the store action and includes critical security context (credential not visible to model) and subsequent steps (share authorization_url, poll status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance: ask the user, share the authorization_url, and poll secret.status. It implies this tool is for new credentials but does not explicitly contrast with secret.revise or specify when not to use it. The flow is described well, but alternative exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0secret.cancelsecret.destinationssecret.revisesecret.statussecret.storeScored across 5 tools
Each tool has a clearly distinct role: status checks a pending request, store initiates a credential request, cancel aborts it, revise replaces it, and destinations lists available targets. No overlap in purpose, making agent selection unambiguous.
All tool names follow a consistent 'secret.<action>' pattern with clear, concise verbs (status, store, cancel, revise) and one noun (destinations). The pattern is uniform and predictable, though 'destinations' is a noun rather than a verb, it still fits the domain prefix style.
With 5 tools, the server is tightly scoped to credential request management. This is within the ideal range and each tool earns its place; no redundancy or bloat.
The tool surface covers the entire lifecycle of a credential request: create (store), read (status), update/replace (revise), delete (cancel), and context (destinations). There are no evident gaps—even revision gracefully handles invalidation of prior authorizations.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Credential isolation for AI agents: placeholder secrets, policy checks, optional human approval.
Secure and manage MCP servers through the Speakeasy AI Control Plane from your agent.
