Skip to main content
Glama

hydra_write_workflow

Writes a validated ETL workflow to a specified path, allowing job and action steps with dependency lists for parallel execution. Skips writing entirely if validation fails.

Instructions

Write a workflow, AFTER validation. A step is either type='job' with the path of a job folder, or type='action'. depends_on is ALWAYS a list: steps with no dependency in common run in parallel. If validation fails, nothing is written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workflow_pathYes
workflow_yamlYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the all-or-nothing behavior: 'If validation fails, nothing is written.' It also explains the parallelism semantics of depends_on, which is helpful behavioral context not present in the structured metadata.

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 compact and front-loaded with the key operation and validation requirement. Every sentence adds useful information: the step model, depends_on behavior, and failure behavior. There is no filler or repetition of the name beyond the opening verb phrase.

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?

Given only two string parameters, an output schema is present, and the description explains the important workflow YAML semantics and failure behavior, the definition is complete enough for an agent to invoke the tool correctly. No critical calling prerequisites are 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 description coverage is 0%, so the description must compensate. It does meaningfully, explaining that workflow_yaml contains steps with type='job' or type='action' and that '`depends_on` is ALWAYS a list.' It leaves the workflow_path parameter to its name, but the core YAML semantics are well covered.

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 operation on a specific resource: 'Write a workflow' and adds the critical condition 'AFTER validation.' It also clarifies the content model (steps of type job or action), which distinguishes it from sibling workflow tools like hydra_read_workflow and hydra_run_workflow.

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 clearly indicates when to use this tool: after validation, and 'If validation fails, nothing is written.' It does not explicitly name a validation alternative or list exclusions, but the sequencing and failure behavior provide solid usage context.

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