Skip to main content
Glama

Set Environment Variable or Secret

secrets_set
DestructiveIdempotent

Sets one environment variable or secret on an app, like adding or editing it on the dashboard's Environment page. Creates the key, or replaces its value when it already exists in that scope (action: created or updated). Takes the app_id from apps_list.

scope is required: app sets the key for every environment (development, staging and production), and environment sets it for the one environment_id (from environments_list) only, where it wins over an app entry of the same key.

is_secret defaults to true: the value goes to Secret Manager and can never be read back. Pass is_secret: false for a plain variable, which the dashboard shows. An existing key keeps its kind: changing is_secret is refused, so call secrets_unset, then secrets_set.

Keys are uppercase (^[A-Z][A-Z0-9_]*$, up to 128 characters) and normalized for you. The value is trimmed, non-empty, at most 8192 characters. Refused names: the HOSTING_ prefix, and MERIDIAN_APP_ID, MERIDIAN_API_URL, MERIDIAN_OAUTH_CLIENT_ID, MERIDIAN_OAUTH_CLIENT_SECRET, which Meridian always sets itself. A key that overrides a variable Meridian manages (the Shopify pair, NODE_ENV, MERIDIAN_API_KEY, DB_*, the REDIS_* set of a ready Redis add-on, ...) is accepted and listed in overrides_managed, one entry per environment it overrides.

THE VALUE IS NEVER RETURNED. The change reaches the app at its next deploy: environments_list reports config_pending_deploy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app_id": "<app_id>",
      "key": "<key>",
      "value": "<value>",
      "scope": "<scope>"
    },
    "name": "secrets_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyYesThe variable name, for example `SHOPIFY_APP_URL`. Uppercased and normalized.
scopeYes`app` for every environment of the app, `environment` for `environment_id` only.
valueYesThe value to set. Trimmed, never returned.
app_idYesThe app uuid returned by `apps_list`.
is_secretNoTrue (the default) for a secret kept in Secret Manager, false for a plain variable the dashboard shows.
environment_idNoRequired when `scope` is `environment`: the environment uuid from `environments_list`.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag a destructive, idempotent, non-read-only write, and the description adds substantial context beyond them: the value is never returned, secrets land in Secret Manager and are unreadable, changes only take effect at the next deploy (`config_pending_deploy`), managed-variable overrides are accepted and reported in `overrides_managed`, and reserved names are refused.

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?

Paragraph structure is logical and front-loaded, moving from action to scope to kind to constraints to side effects. It is dense but slightly long, with a small redundancy in repeating that the value is never returned (already in the `value` schema description).

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?

For a 7-parameter mutation with no output schema, the description covers everything an agent needs: inputs and their sources, validation and refusal rules, override reporting, and when the effect becomes visible. No meaningful gap remains.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: the key regex and 128-char limit, value trimming and 8192-char cap, `is_secret` defaulting to true and being immutable on an existing key, and the exact behavior of `scope`/`environment_id` including precedence.

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 ('Sets one environment variable or secret on an app') and immediately clarifies the create-vs-replace semantics via `action`: `created` or `updated`. It is clearly distinguishable from `secrets_unset` and `secrets_list`, which are named or implied by contrast.

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 routes the agent: `app_id` comes from `apps_list`, `environment_id` from `environments_list`, and changing `is_secret` requires `secrets_unset` first because it is refused here. The scope choice is spelled out with a precedence rule (`environment` wins over an `app` entry of the same key).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources