Valet

Set environment variables

set_env_vars

DestructiveIdempotent

Set environment variables on an app or agent, as name to value. A secret, the default, is encrypted and never shown again; pass secret false for plain configuration, which is readable from the dashboard. A value given here passes through this conversation, which is a real cost and the user's call: say that they could instead enter it on the dashboard, where it goes straight to Valet. Setting a name that exists replaces its value, which is why this is destructive. The process sees new values on its next start. The answer names the variables set and never their values. Requires connecting a Valet account.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Required. The app's or agent's name.
`vars`	Yes	Required. Variable name to value.
`secret`	No	Whether to store the values as secrets, which are encrypted and never shown again. Omit for true; pass false for plain configuration, readable from the dashboard.
`org_name`	No	The Valet organization it belongs to. Omit to use the organization the account joined first.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

removedInput schema / properties / kind

Removed value: -{
-  "description": "How to store them. Omit for secret.",
-  "enum": [
-    "secret",
-    "plain"
-  ],
-  "type": "string"
-}

addedInput schema / properties / secret

Added value: +{
+  "description": "Whether to store the values as secrets, which are encrypted and never shown again. Omit for true; pass false for plain configuration, readable from the dashboard.",
+  "type": "boolean"
+}

AddedOct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it explains that secrets are encrypted and never shown again, that an existing name is replaced (justifying the destructive hint), that the process only sees new values on its next start, that the answer names variables but never values, and that a Valet account is required. This is exactly the contextual disclosure annotations cannot carry.

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?

Front-loaded with the action, and each sentence carries information. It is long and slightly repetitive around the secret/dashboard explanation, but almost no sentence is wasted.

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?

With no output schema and a nested object parameter, the description still covers return shape ('names the variables set and never their values'), auth requirement, timing of effect, and the destructive replacement semantics. Nothing needed to call it correctly is missing.

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 meaning the schema lacks — notably that the 'vars' values pass through this conversation as a real cost, and that secret defaults to true while false yields dashboard-readable plain configuration.

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?

States a specific verb and resource ('Set environment variables on an app or agent') plus the input form ('as name to value'). An agent can immediately distinguish this from unset_env_vars and list_env_vars among its siblings.

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?

Gives real selection context: it says a value passed here travels through the conversation and suggests the user could instead enter it on the dashboard, which routes straight to Valet. It also explains the secret-vs-plain choice. It does not explicitly name sibling alternatives or exclusions, so it falls just short of a 5.

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

All Valet tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?