Skip to main content
Glama
amintt2

coolify-mcp

by amintt2
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create or update environment variables

set_envs
Idempotent

Set one or many environment variables on a Coolify app or service. Existing keys update, missing keys are created, and the response lists each key's status without showing values. Dry-run previews changes; restart or deploy applies them.

Instructions

Upsert one or many environment variables on an application or service in a single call: existing keys are updated, missing keys created, identical ones left alone. Returns per key created / updated / unchanged plus which fields changed — values are never echoed. Flags you omit keep their current value on update. For applications, the main and preview copies of a key are separate (use is_preview). Use dry_run to preview. Changes only take effect after restart_application / restart_service, or deploy for build-time variables.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envsYesVariables to upsert.
dry_runNoReport what would change without calling the mutating API. Allowed even in read-only mode.
resourceYesThe resource: its uuid, its exact name, or a unique part of its name or domain (e.g. "api" or "app.example.com").
resource_typeNoRestrict lookup to applications or services. Omit to search both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (idempotent, non-destructive), the description discloses key behavioral traits: existing keys are updated, missing created, identical left alone (idempotency), values are never echoed, omitted flags keep current values, preview vs main separation, dry_run mode, and the requirement to restart or deploy for changes to take effect. This is rich behavioral context that significantly aids correct invocation.

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?

The description is a single dense sentence that front-loads the main purpose, then logically flows through key behaviors. Every clause adds necessary information without redundancy. It is appropriately concise for the complexity of the tool.

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 tool with multiple parameters, flags, and side effects, the description covers all critical aspects: return format, value handling, flag semantics, preview vs main, dry_run, and the required follow-up actions (restart or deploy). No essential operational detail is missing, making it complete for correct usage.

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 each parameter already has a description. The tool description adds semantic meaning beyond the schema by explaining that omitted flags retain their current values, that is_preview targets the preview copy, and that dry_run is allowed even in read-only mode. It clarifies the upsert behavior and effect of flags, which goes beyond the basic parameter definitions.

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 ('Upsert') and resource ('environment variables on an application or service'), and clearly distinguishes it from siblings like list_envs and delete_env by defining its scope and behavior. It also specifies the return status per key, which removes ambiguity about what the tool does.

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?

The description provides clear context on when to use the tool, including that it performs an upsert and that changes take effect only after a restart or deploy. It also explicitly suggests using dry_run to preview, which is a usage directive. However, it does not explicitly name alternative tools or state 'when not to use', though the context makes it evident.

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