kad.dev

Set environment variables

set_env_vars

DestructiveIdempotent

Write a project's environment variables and roll the deployed pods so the new values take effect. MERGES by default: send only the vars you want to create or change — every other var, including secrets you never read, is left exactly as it is. Pass delete[] to remove vars by name. Pass mode="replace" ONLY to overwrite the entire set and drop every var you didn't list. Masked values from get_settings are not accepted back: a payload containing "***" is rejected. Requires a read-write token.

Input Schema

Name	Required	Description
`envs`	Yes	the environment variables to write; in the default merge mode only these names are created/updated and every other var keeps its current value, so changing one var never requires reading (or echoing back) the project's secrets
`mode`	No	optional; merge (DEFAULT) upserts only the vars in envs and leaves the rest untouched; replace overwrites the WHOLE set and DELETES every var not listed — only pass replace when a wipe is the intent
`delete`	No	optional; env var names to remove (merge mode only). Platform-provisioned credentials (DATABASE_URL, S3_*) cannot be removed this way
`project_id`	Yes	the project id (from list_projects)

Output Schema

Name	Required	Description
`ok`	Yes
`status`	No	present, and always "pending_approval", only when this call was parked instead of run immediately because the project's (or kad-back's own) plan-mode setting requires a human to approve it first
`message`	Yes
`plan_id`	No	poll get_plan_status with this id for the eventual outcome
`approve_at`	No	the kad.dev dashboard URL a human approves or rejects this plan from
`expires_in_s`	No	the plan can no longer be approved after this many seconds

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description adds critical context beyond them: deployed pods are rolled, unlisted vars and secrets are preserved in merge mode, "***" payloads are rejected, and a read-write token is required. This is exactly the extra operational context annotations cannot convey.

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?

Five tight sentences, front-loaded with the action and side effect, then merge semantics, deletion, the replace warning, and the token requirement. No 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?

A destructive, multi-mode mutation tool is fully framed: default behavior, dangerous mode, deletion path, auth requirement, and a rejection rule for masked input. An output schema exists, so return values need not be described.

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 already 100%, so the baseline is 3. The description still adds practical meaning: merge vs replace semantics of envs, the merge-only restriction on delete[], and the platform-provisioned credential exclusion. It stops short of covering build_exposed, which is left entirely to the schema.

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 (write a project's environment variables) plus the consequential side effect (roll the deployed pods). It is clearly distinct from sibling read tools like get_settings and get_build_env.

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 the default behavior (merge), when to use delete[], and a strong when-not rule: pass mode="replace" ONLY to wipe the whole set. It also warns against echoing back masked values from get_settings.

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

All kad.dev 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?