Dockhold

Store an app secret

set_app_secret

Idempotent

Store a sensitive value (an API key, a token, a password, a connection string) for one app. Use this instead of set_app_variable whenever the value would be damaging if someone else read it. The value is encrypted at rest, is injected into the app's environment under the name you give, and the app restarts to pick it up. Storing a secret takes effect on the next boot, so call this before telling the user the app is ready. This tool never reads a value back: there is no way to retrieve a stored secret through this connection, only through the dashboard while signed in. Two things to tell the user before you call it. First, this token can write secrets to every app on their account, not only this one. Second, any value they give you has passed through your context, so prefer a value you read from a local file such as .env over one you asked them to type into the chat, and suggest they rotate anything that was pasted. If the vault key name is already used by a different app, this call is refused rather than overwriting it, and the message tells you what to pass as vault_key_name.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The environment variable name the app code reads, for example STRIPE_SECRET_KEY
`value`	Yes	The secret value. It is encrypted at rest and is never returned by any tool.
`app_id`	Yes	The app id returned by list_apps
`vault_key_name`	No	Optional name for the stored value in the account vault. Defaults to name. Pass an explicit one when the default is already used by another app.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the value is encrypted at rest, injected into the environment, triggers a restart, takes effect on next boot, and can never be read back through this connection. It also warns that the token can write secrets to every app on the account and that conflicting vault key names cause a refusal. This is far more than annotations alone provide.

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

Conciseness5/5

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

The description is long but every sentence carries operational or safety-critical information. It is front-loaded with the core purpose and then layers in timing, retrieval limitations, permission scope, and edge-case behavior. Nothing feels redundant or filler.

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?

Given four parameters, no output schema, and the sensitivity of the operation, the description covers the full calling picture: when to use it, what happens to the value, when to call it, what to warn the user about, and how to handle vault key conflicts. An agent has everything needed to invoke it correctly and safely.

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 description coverage is 100%, so the schema already documents all parameters. The description adds valuable context beyond the schema, especially the vault_key_name conflict behavior and the fact that the value is exposed via the environment under the given name. This pushes it above the baseline.

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

Purpose5/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: storing a sensitive value for one app. It explicitly distinguishes itself from set_app_variable, making the tool's role unmistakable even among many sibling tools.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: prefer this over set_app_variable whenever the value would be damaging if read by someone else. It also advises calling it before telling the user the app is ready, and explains when to pass vault_key_name, so an agent knows exactly when and how to invoke it.

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

All Dockhold tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct operation: deployment, monitoring, scaling, configuration, or listing. There is no overlap; agents can easily select the correct tool.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., deploy_app, get_app_logs, resize_database). No naming irregularities.

Tool Count5/5

12 tools cover the core operations of a deployment platform without bloat or missing essentials. The count is well-scoped.

Completeness4/5

Covers deploy, manage, scale, and monitor effectively. Missing only minor operations like deleting an app or environment variable, but the core workflow is complete.

Resources

Need Help?