Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_variable

Set or merge project and service environment variables by key, defaulting to write-only secrets. Use it for non-sensitive values like log levels, flags, or public URLs; ask humans for credentials.

Instructions

Set/merge a project's variables; write-only unless secret=false. Returns names only.

    WARNING: the values you pass here transit this agent's transcript in
    plaintext, whether ``secret`` is omitted, ``true`` or ``false``. For any
    credential, do not pass the value at all: ask the human to run
    ``nerdit vars set <project> --secret --prompt KEY`` (hidden input) and
    only ever name ``KEY`` yourself. Use this tool for values that are fine
    to appear in a transcript (a log level, a feature flag, a public URL).

    A variable reaches a service's environment at launch. Precedence, lowest
    to highest: the manifest ``env`` table, the project scope, the service
    scope, then platform-injected bindings (``OPENAI_BASE_URL``,
    ``DATABASE_URL``…), which a variable can never override. Setting a key
    again flips its plain/secret flag in that scope. Only the project's owner
    or an admin may write (another token gets 403).
    A running service picks the change up on its next restart or redeploy.
    The machine-wide scope is not reachable here: use ``set_secret`` with
    ``shared``.

Input Schema

NameRequiredDescriptionDefault
secretNoOmit (or ``true``) for a write-only SECRET: no API, tool or dashboard ever returns the value again. ``false`` is the explicit PLAIN write: the project's owner or an admin can read the value back. When unsure, omit it.
valuesYesKEY → value pairs merged into the scope: a listed key is overwritten, an unlisted one kept. Key names are env-var identifiers (``[A-Za-z_][A-Za-z0-9_]*``); a value may be multi-line but may contain no NUL and no control character other than tab/newline/CR. An empty map is refused.
projectYesImmutable prj_ ID or name of the project to modify. An unknown name creates it for your token; an unknown or retired ID is refused.
serviceNoService inside the project (``web`` for a single-app project) to set the key for that service only; omit for the project scope, shared by every service of the project. On a key set in both, the service scope wins.
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses write-only vs plain behavior, transcript plaintext risk, return shape, precedence rules, owner/admin authorization with 403, and the fact that running services only pick up changes on restart or redeploy.

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?

The description is front-loaded with the core purpose and return behavior, then moves into safety warnings and operational details. It is long, but most content is high-value for a mutation tool that handles credentials and has no annotations.

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 the absence of annotations and output schema, the description is complete enough: it explains return values, permissions, precedence, secret handling, transcript risk, restart semantics, and the correct alternative for machine-wide scope.

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 already 100%, so the schema documents each parameter in detail. The description adds useful meaning beyond the schema, especially around credential handling, secret-vs-plain semantics, and service/project precedence, though it does not discuss idempotency_key.

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: set/merge a project's variables. It also distinguishes the write-only secret behavior and notes that only names are returned, so an agent can immediately understand the operation.

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?

It explicitly says when not to use the tool for credentials and directs the agent to ask the human to run a hidden-input CLI command instead. It also names an alternative for machine-wide scope: use set_secret with shared. This is unusually clear routing guidance.

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

Deploy Server

Other Tools