Skip to main content
Glama

fline

by sh.fline
OverviewDiscussionsAdmin

Set an environment variable

set_env
DestructiveIdempotent

Set one environment variable for the project. secret says which store it goes to and it is REQUIRED, because the two are not interchangeable and there is no default that is right for both. secret=false writes a PLAINTEXT value: it is stored as written, returned by list_env_names, shown in the console, and rendered into every service's environment — a model name, a log level, a public URL, a feature flag. Choose it only for a value you would paste into a public repository. secret=true writes to the secret store, which no tool and no screen can read back, ever, this one included. Use it for a value you already hold: one you generated yourself, such as a random session key, or one the person already pasted into the chat, in which case suggest they replace it with a fresh key through get_secrets_link. For a password or key the person has not given you, use get_secrets_link; never ask them to paste it into the chat. secret=true replaces a secret that is already set. secret=false has four refusals, each with a way on. A name whose final underscore-separated segment is KEY, TOKEN, SECRET, PASSWORD, PASS, PWD, CREDENTIAL, CREDENTIALS or DSN is refused: rename the variable, or send the same value with secret=true. An empty value is refused: an empty variable is indistinguishable from an absent one and the deploy fails on it later, so declare the name and leave the value to a person instead. A name that already holds a secret is refused: call delete_env_name first, then set it. And a name the plan binds to a managed database or an addon is refused, because the platform provisions that and writes the connection string itself. Do not set such a name with secret=true either: the platform skips wiring a variable that already holds a value, so the database is never connected. A plaintext value survives the next analysis; a secret still does not. Either takes effect on the next deploy or restart.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
valueYes
secretYes
project_idYes
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare destructiveHint and idempotentHint, and the description adds substantial context beyond them: plaintext values are visible in list_env_names, the console, and every service environment, while secret values are unreadable by any tool. It also discloses the four refusal rules, the platform-managed-database trap, and that changes apply on next deploy/restart. The only gap is it never mentions idempotency behavior even though idempotentHint=true is asserted.

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 required-parameter rule and the plaintext/secret split, and nearly every sentence carries a rule or remedy worth keeping. It is nonetheless long, with a few cryptic or redundant lines (e.g. 'A plaintext value survives the next analysis; a secret still does not') that could be tightened.

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

Completeness4/5

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

For a destructive, 5-parameter, no-output-schema tool, the description covers refusal modes, side effects, visibility, and alternatives comprehensively. Missing only the `idempotency_key` parameter semantics and any statement about what the call returns or signals on success.

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 0%, so the description carries the burden and largely does: it explains why `secret` is required, what each mode means, naming rules for `name`, and the empty-`value` refusal. However, `idempotency_key` is never mentioned, and `project_id` is left implicit, so it does not fully compensate for the 0% coverage.

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 opening sentence gives an exact verb+resource ('Set one environment variable for the project') and the body immediately distinguishes the two write modes, making this clearly separable from siblings like declare_env_names, delete_env_name, and get_secrets_link.

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?

Explicitly states when to use secret=true vs secret=false, when to use get_secrets_link instead ('for a password or key the person has not given you'), and enumerates four refusal conditions each paired with a remedy. Nothing is left to inference.

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

All fline toolsInspect
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