Skip to main content
Glama
Deraiven
by Deraiven

zadig_workflow_apply

Create or update a custom CI/CD workflow in Zadig. Use dry-run mode to preview changes before applying them.

Instructions

Create or update a custom workflow. mode can be auto, create, or update. Defaults to dry_run=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoauto
confirmNo
dry_runNo
workflowYes
project_keyNo
workflow_nameYes
allow_redactedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description must carry behavioral disclosure, but it only restates the dry_run default already in the schema and lists mode values. It never discloses that this is a mutating operation, what confirm controls, whether auto can destroy or overwrite an existing workflow, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and has no filler, and it opens with the core purpose. However, the brevity crosses into under-specification because it omits behavioral and parameter context while repeating schema defaults.

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 7-parameter apply tool with no annotations and a nested workflow object, the description is materially incomplete: it does not explain the workflow payload, mode semantics, confirm's effect, or project_key's role. The presence of an output schema reduces the need to document return values, but the invocation path is still underspecified.

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 needs to explain parameters; it only clarifies mode's allowed values and dry_run's default. workflow, confirm, project_key, and allow_redacted remain unexplained, leaving over half of the parameters semantically opaque.

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?

Description states a specific action ('Create or update') on a specific resource ('custom workflow'), and this distinguishes 'apply' from list/get/delete siblings even though it overlaps with create/update. It could be a 5 if it explicitly contrasted with the create/update siblings, but it is unambiguous 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 Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use apply instead of workflow_create or workflow_update, both of which appear as siblings. 'mode can be auto, create, or update' implies a decision point but does not explain when each mode should be selected or when this tool is preferable.

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