Skip to main content
Glama

validate_workflow

Check workflow syntax for errors before execution. Parses DSL content and returns validation status with any issues found.

Instructions

Validate DSL workflow syntax.

Parses DSL and checks for syntax errors without executing the workflow. Returns validation status and any errors found.

Args: dsl: Workflow content in DSL format

Returns: Validation result with is_valid, errors, and warnings

Examples: validate_workflow(dsl_content)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dslYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The validate_workflow tool handler: parses DSL syntax using DSLParser, returns validation status, errors, node/section counts on success, or error details on failure.
    def validate_workflow(dsl: str) -> dict:
        """Validate DSL workflow syntax.
    
        Parses DSL and checks for syntax errors without executing the workflow.
        Returns validation status and any errors found.
    
        Args:
            dsl: Workflow content in DSL format
    
        Returns:
            Validation result with is_valid, errors, and warnings
    
        Examples:
            validate_workflow(dsl_content)
        """
        try:
            parser = DSLParser()
            workflow_ast = parser.parse(dsl)
    
            # If parsing succeeded, it's valid
            return {
                "is_valid": True,
                "errors": [],
                "warnings": [],
                "node_count": sum(len(section.nodes) for section in workflow_ast.sections),
                "section_count": len(workflow_ast.sections)
            }
    
        except Exception as e:
            return {
                "is_valid": False,
                "errors": [str(e)],
                "warnings": [],
                "message": "DSL syntax error"
            }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a read-only validation (no execution), returns validation status and errors, and checks syntax. However, it does not mention potential limitations like rate limits, authentication needs, or what happens with invalid input beyond errors, leaving some gaps.

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 well-structured and front-loaded, starting with the core purpose, followed by behavior, args, returns, and an example. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

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

Completeness4/5

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

Given the tool's moderate complexity (validation without execution), no annotations, and an output schema (which covers return values), the description is mostly complete. It explains purpose, usage, and parameters adequately, but could benefit from more behavioral details like error handling or prerequisites to be fully comprehensive.

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?

The description adds meaningful semantics beyond the input schema, which has 0% coverage. It explains that the 'dsl' parameter is 'Workflow content in DSL format,' providing context not in the schema. With only one parameter, this is sufficient to compensate for the low schema coverage, though more details on DSL format could enhance it.

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 clearly states the tool's purpose with a specific verb ('validate') and resource ('DSL workflow syntax'), distinguishing it from siblings like execute_workflow (which executes) or read_workflow (which reads). It explicitly mentions parsing DSL and checking for syntax errors without execution, making the purpose unambiguous.

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 for when to use this tool: to validate workflow syntax before execution, as implied by 'without executing the workflow.' However, it does not explicitly state when not to use it or name alternatives (e.g., validate_template_parameters for templates), so it lacks full exclusion guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/christian-byrne/comfy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server