Zigflow
About
Declarative workflow orchestration for Temporal using the CNCF Serverless Workflow specification.
Details
- Author
- Unknown
- Categories
- Developer Tools, Automation, Infrastructure
Jump to
Hosted, public and read-only. No install and no API key required.
- Scaffold a workflow from a real, supported example instead of from scratch
- Validate workflow YAML against the current DSL schema before you commit
- Keep your assistant aligned with the schema for your Zigflow version
- Stay safe: the server is read-only, never connects to Temporal and never reads your files
The hosted server uses the MCPStreamable HTTPtransport. Any MCP client that supports remote (HTTP) servers can connect by using the endpoint:
Add it as a remote MCP server in your client. No credentials are required.
Each MCP client manages servers differently, and those formats change often. Zigflow documents the endpoint and the tools it provides. For how to add a remote MCP server in a specific client, see the officialMCP documentation.
The server exposes five read-only tools.
Lists the bundled workflow examples with their name, title, description and tags. Takes no parameters. Use this before callingget_exampleto discover the patterns that are available.
Returns a named example, including its YAML content and metadata (name, title, description and tags). Thenamefield must match an identifier returned bylist_examples. If the name is unknown, the error message lists the available names.
Returns the Zigflow DSL JSON Schema for the current version. Theoutputfield accepts"json"(the default) or"yaml". Use this to understand valid workflow structure before generating or validating a definition.
Set the optionaldeffield to return a single schema definition from$defs, for example{ "def": "taskList" }. The name must match a$defskey exactly. Unknown definitions return a tool error.
Returns authoritative documentation for a single task type. Thetask_typefield must be one of the supported task types:call,do,for,fork,listen,raise,run,set,switch,tryorwait. An unknown task type returns a tool error that lists the supported types.
The response aggregates several sources so a client does not need to scrape the documentation site:
Use this to learn how a specific task type works before authoring YAML. The schema and reference page are served from the same sources as theDSL reference, so they stay in step with the engine.
Validates a workflow YAML string and returns structured errors. Theyamlfield must contain the full workflow definition as a string, not a file path.
Each error includes astagefield that identifies where in the validation pipeline the failure occurred:
Errors also include amessage. Errors from theschemaandstructstages additionally include apaththat pinpoints the failing field.structstage errors also includeruleandparamfields describing the failing rule. A successful response includes"valid": trueand no errors.
Recognised validation errors carry two further fields:
Thecodeis additive metadata. Themessageis never rewritten to embed it. ThedocumentationURL is derived from thecode, so the two always agree. The URL is built by lowercasing the code, dropping theERR_prefix and replacing underscores with hyphens, soERR_INVALID_TASK_QUEUEbecomeshttps://zigflow.dev/errors/invalid-task-queue.
Errors without a recognisedcodeomit both thecodeanddocumentationfields. For example, an invalidtaskQueuereturns:
{ "stage": "schema", "path": "$.document.taskQueue", "code": "ERR_INVALID_TASK_QUEUE", "message": "pattern: \"Not A Valid Queue\" does not match regular expression \"^a-zA-Z0-9?$\"", "documentation": "https://zigflow.dev/errors/invalid-task-queue" }
A typical AI-assisted authoring session:
- Calllist_examplesto browse available patterns
- Callget_exampleto inspect a relevant example
- Callget_schemato understand the DSL structure
- Callget_task_docsto learn a specific task type in depth
- Generate or modify a workflow YAML
- Callvalidate_workflowto check it
- Correct errors based on thestageandmessagefields
- Repeat from step 6 until valid
Starting from a known example produces more accurate results than generating from scratch. Zigflow's DSL is a deliberate subset of the Open Workflow Specification (formerly Serverless Workflow). The schema and bundled examples define what is actually supported.
AI-generated workflows are a starting point.validate_workflowconfirms structural validity against the DSL schema. It does not verify that the workflow logic is correct for your use case. Review generated workflows before using them in production.
The server is intentionally limited in what it can do, which keeps it safe to expose:
- No filesystem access.All tool operations use input from the request or data embedded in the binary. The server does not read or write host files.
- No Temporal access.The server does not connect to Temporal and cannot start, query or affect workflow executions.
- Read-only operations.Every tool returns information or validates input. No tool mutates state.
- Stateless requests.Each request is independent. The HTTP transport holds no per-session state, and request bodies are size-limited to bound memory use.
The hosted server adds no authentication of its own. If you self-host and expose it publicly, apply authentication and access control at the reverse proxy or ingress layer.
You can run the same server yourself, either over HTTP or over stdio.
The server listens on0.0.0.0:8080by default. Use--addressto change the listen address:
zigflow mcp --transport http --address 0.0.0.0:9000
Because the HTTP transport is stateless, it runs well behind a reverse proxy, ingress or service such as Cloudflare, and scales horizontally without session affinity.
The stdio transport communicates over stdin/stdout and is the usual choice for a client that launches and manages the server locally as a subprocess. It is not meant to be run interactively in a terminal.
An unknown--transportvalue fails the command rather than falling back to a default.
Passing a file path tovalidate_workflow.The tool accepts a YAML string, not a file path. Read the file contents first and pass the YAML as a string.
Running the stdio transport directly in a terminal.With the default stdio transport, the server communicates over stdin/stdout using the MCP protocol. It will not print anything useful when run interactively. Connect to it through an MCP client, or use the HTTP transport for a network-facing server.
- DSL reference: full schema for workflow definitions
- Schema: the JSON Schema for workflow files
- Examples: bundled workflow patterns
- Using the CLI: command-line validation and workflow execution
This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.
Remote runtimes for validation and offload jobs.
All Azure MCP tools in a single server. The Azure MCP Server implements the MCP specification to create a seamless connection between AI agents and Azure services. Azure MCP Server can be used alone or with the GitHub Copilot for Azure extension in VS Code.
The Railway MCP Server enables natural language interaction with your Railway projects and infrastructure. Ask your IDE or AI assistant to create projects, deploy templates, manage environments, pull variables, redeploy services, and more.
The Shipyard CLI provides an MCP server for agents to manage Shipyard environments directly: by pulling logs, comparing branches, running tests, and stopping/starting environments..
Secure virtual machines for agents hosted by Superserve
Execute any LLM-generated code in the YepCode secure and scalable sandbox environment and create your own MCP tools using JavaScript or Python, with full support for NPM and PyPI packages
Provides tools to interact with the Ansible Automation Platform API for automation tasks.
A MCP server for managing Brev development environments using the Brev CLI.
Provides an offline AWS CDK API reference.
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
