Skip to main content
Glama

Validate workflow

validate_workflow
Read-onlyIdempotent

Compile a workflow without deploying it and report every error with its node, so you can catch issues after each edit and before deployment.

Instructions

Compile a workflow without deploying it and report every error, each with the node it concerns. Use it after every edit and before deploy_workflow. Checks the saved graph by workflowId, or an unsaved graph passed as nodes and edges (given with a workflowId, they replace the saved ones for this check only). Set includeCode to also get the generated Worker script and its metadata (target, bindings, size) to show the user.

Input Schema

NameRequiredDescriptionDefault
edgesNoEdges to check instead of the saved ones. Pass with nodes.
nodesNoNodes to check instead of the saved ones. Pass with edges.
workflowIdNoThe workflow's id, from list_workflows or create_workflow.
includeCodeNoAlso return the compiled script and metadata when valid. Default false, to save tokens.

Output Schema

NameRequiredDescriptionDefault
validYes
errorsYes
scriptNo
metadataNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description reinforces this with the key non-persistence disclosure: unsaved nodes/edges 'replace the saved ones for this check only.' It also explains what includeCode returns (Worker script plus target, bindings, size), which annotations and schema do not cover.

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?

Three tightly packed sentences, front-loaded with what the tool does, then when to use it, then the two modes and the optional output flag. No filler and every clause carries distinct information.

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?

An output schema exists, yet the description still tells the agent what kind of result matters (per-node errors; code and metadata when includeCode is set). Combined with the validation-timing guidance, nothing an agent needs to call this correctly is missing.

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 the baseline is 3, but the description adds real cross-parameter semantics the schema only hints at: nodes/edges combine with workflowId to shadow saved data for this check only, and includeCode has an intent ('to show the user') beyond the schema's terse note. Slightly short of 5 since individual parameter shapes are 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 ('Compile a workflow without deploying it') plus the output ('report every error, each with the node it concerns'). The contrast with deploying makes it immediately distinguishable from deploy_workflow and get_workflow without opening either schema.

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 prescribes timing and the alternative it precedes: 'Use it after every edit and before deploy_workflow.' It also names both invocation modes (saved graph by workflowId, or unsaved graph via nodes and edges) so the agent knows which path to take.

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