Skip to main content
Glama
Deraiven
by Deraiven

zadig_environment_delete

Remove unwanted Zadig environments with confidence using dry-run default and mandatory confirmation. Provide environment name and project key.

Instructions

Delete a Zadig environment. Defaults to dry_run=true and requires confirm=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNo
dry_runNo
env_nameYes
is_deleteNo
productionNo
project_keyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the operation is non-destructive by default (dry_run=true) and gated by confirm=true. However, it does not explain the consequences of a real deletion (permanence, cascading resource removal) or what the dry-run output looks like.

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?

A single sentence that front-loads the action and packs the two most important safety behaviors into the same line. No filler or redundant phrasing.

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

Completeness2/5

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

For a destructive operation with six parameters and no annotations, the description is thin. It fails to explain target selection nuances (production, project_key), the meaning of is_delete, or the operational difference between dry-run and confirmed deletion. The output schema covers return shape, so return values are less critical, but the missing context leaves an agent guessing on how to correctly scope the deletion.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only clarifies dry_run and confirm (default and requirement), while env_name, is_delete, production, and project_key remain unexplained. The purpose of is_delete is especially ambiguous, and no guidance is given on how production and project_key affect the target environment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Delete') and specific resource ('Zadig environment'), making the tool's primary function unambiguous. It is distinct from sibling tools like environment_service_delete because it targets the environment itself, but it does not explicitly differentiate itself from related alternatives.

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 communicates critical invocation conditions: dry_run defaults to true and confirm must be true to actually delete. This gives clear context on how to use the tool safely, though it does not mention when to prefer alternatives such as environment_apply or environment_service_delete.

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