About workflows-mcp-server
workflows-mcp-server is a YAML playbook library for LLM agents that need reusable sequences of MCP server and tool calls. It supports versioned permanent workflows and temporary drafts, with changes indexed automatically.
Key features
- 01List and filter workflows
- 02Retrieve versioned definitions
- 03Create permanent and temporary YAML
- 04Delete after user confirmation
- 05Automatic file watching and indexing
- 06stdio and Streamable HTTP
Use cases
- 01Find a playbook by category or tags
- 02Reuse a versioned sequence of MCP calls
- 03Draft a workflow before making it permanent
- 04Update the library by editing YAML files
MCP support
Exposes five MCP tools to list, retrieve, create, and delete YAML workflows. Workflows describe sequences of MCP server and tool calls; the server supports stdio and Streamable HTTP.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
npx -y @cyanheads/workflows-mcp-serverWORKFLOWS_DIRAbsolute or relative path to the workflows root directory.GLOBAL_INSTRUCTIONS_PATHPath to the global instructions markdown file. Derives from WORKFLOWS_DIR when not set.WATCHER_DEBOUNCE_MSMilliseconds to debounce filesystem change events before rebuilding the index.MCP_LOG_LEVELSets the minimum log level for output (e.g., 'debug', 'info', 'warn').MCP_TRANSPORT_TYPESelects the HTTP transport.MCP_HTTP_HOSTThe hostname for the HTTP server.MCP_HTTP_PORTThe port to run the HTTP server on.MCP_HTTP_ENDPOINT_PATHThe endpoint path for the MCP server.MCP_AUTH_MODESecretAuthentication mode to use: 'none', 'jwt', or 'oauth'.Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.
Tools
5Saved tool list · updated 3d ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| tags | array | No | Filter to workflows that have ALL of these tags (AND match, case-insensitive, each tag trimmed of leading and trailing whitespace). Omit to skip tag filtering. |
| query | string | No | Keyword filter matched case-insensitively against each workflow name and description. A workflow matches if either field contains the query. Leading and trailing whitespace is ignored. Omit to skip keyword filtering. |
| category | string | No | Filter to workflows whose category contains this string (case-insensitive substring match). Leading and trailing whitespace is ignored. Omit to return all categories. |
| includeTools | boolean | No | When true, each result includes a unique list of server/tool pairs used across its steps. |
Details
From the project README@cyanheads/workflows-mcp-server
Store, query, and create YAML workflow playbooks for LLM agents via MCP. STDIO or Streamable HTTP.
Overview
A declarative workflow library for LLM agents, backed by local YAML files. Store, list, and retrieve named, versioned multi-step playbooks — each a sequence of MCP server/tool calls — for permanent reuse or one-shot temporary runs. Edits to the YAML files are picked up automatically.
Tools
| Tool | Description |
|---|---|
workflow_list | List all permanent workflows in the index, with optional keyword, category, and tag filters. |
workflow_get | Retrieve a complete workflow definition by name, with global instructions prepended. |
workflow_create | Write a new permanent workflow YAML to the library. |
workflow_create_temp | Write a temporary workflow draft, indexed but excluded from list results, kept until deleted. |
workflow_delete | Remove a permanent workflow or a temporary draft by name and optional version, after the user confirms the resolved target. |
Capability reference
workflow_list tool
- Optional
query(name and description),category(substring), andtags(all must match) filters, case-insensitive; temporary drafts are never listed - Sorted by name, then highest version first; an empty result carries a
noticeechoing the applied filters includeTools: trueadds each workflow's uniqueserver/toolpairs
workflow_get tool
nameplus an optional semverversion; omitversionfor the highest available, drafts included- Returns the full workflow, its
source(permanentortemp), andglobalInstructionsfromglobal_instructions.md(nullwhen absent); fails withnot_foundorversion_not_found - Template placeholders such as
{{input.foo}}come back verbatim — the server never interpolates them
workflow_create tool
name, semverversion,description,author,category, andsteps(plus optionaltags); stored as one file pername@versionundercategories/<category>/, with created and updated dates stamped- Returns the
key(name@version) andfilePath; fails withalready_existswhen a permanent workflow or a draft holds the key,invalid_input, orwrite_failed
workflow_create_temp tool
- The
workflow_createfields minuscategory; stored undertemp/, retrievable withworkflow_get, never listed, and kept untilworkflow_deleteremoves it statusiscreated, oroverwrittenwhen it replaced the draft of the same key (keeping that draft'screated_date); a key held by a permanent workflow fails withalready_exists
workflow_delete tool
nameplus an optionalversion(omitted: the highest across permanent workflows and drafts); the user confirms the resolvedname@version, source, and file before anything is deleted, so a client without elicitation cannot delete- Returns the deleted workflow's
source, plus anoticewhen another file declaring the same key now takes its place; fails withcancelled,confirmation_invalid(a prompt never issued, already answered, older than 10 minutes, or issued to another caller),target_changed(the file or its content changed after the user saw it), ornot_found
Features
Built on @cyanheads/mcp-ts-core: stdio and Streamable HTTP transports, pluggable auth (none / jwt / oauth), swappable storage (in-memory, filesystem, Supabase, Cloudflare KV/R2/D1), structured logging with optional OpenTelemetry tracing.
Workflow library:
- YAML files under
categories/andtemp/are validated at index time; an invalid file is skipped and logged, never crashes the server - In-memory index keyed by
name@version, read from each file's content rather than its name and kept fresh by a debounced recursive watcher; a permanent workflow outranks a draft with the same key - Versions are canonical semver everywhere: a leading
v, surrounding whitespace, and build metadata are dropped, sov1.0.0+build.5is stored, keyed, and looked up as1.0.0 - Creates and deletes run one at a time, so each existence check holds until its write lands; filenames carry a hash of
name@version, so keys whose slugs coincide never share a file - An
_index.jsonsnapshot is written on every rebuild for external tooling and debugging
Agent-friendly output:
- Discriminated output —
source: "permanent" | "temp"on everyworkflow_getresponse and typedreasoncodes (not_found,version_not_found,already_exists,cancelled,confirmation_invalid,target_changed,index_unavailable, …) on failures, so callers branch on data instead of parsing error strings - No extra round trip —
workflow_getalways returnsglobalInstructionsalongside the workflow definition in the same response - Response shaping —
workflow_list's optionalincludeToolsflag pre-derives the uniqueserver/toolpairs used by a workflow, and an empty result echoes the applied filters with a broadening hint instead of returning nothing
Getting started
No API keys required. The server reads from a local workflows-yaml/ directory by default.
Add the following to your MCP client configuration file:
{
"mcpServers": {
"workflows-mcp-server": {
"type": "stdio",
"command": "bunx",
"args": ["@cyanheads/workflows-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"WORKFLOWS_DIR": "/absolute/path/to/your/workflows-yaml"
}
}
}
}
Or with npx (no Bun required):
{
"mcpServers": {
"workflows-mcp-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@cyanheads/workflows-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"WORKFLOWS_DIR": "/absolute/path/to/your/workflows-yaml"
}
}
}
}
Or with Docker:
{
"mcpServers": {
"workflows-mcp-server": {
"type": "stdio",
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "MCP_TRANSPORT_TYPE=stdio",
"-v", "/absolute/path/to/your/workflows-yaml:/workflows-yaml",
"-e", "WORKFLOWS_DIR=/workflows-yaml",
"ghcr.io/cyanheads/workflows-mcp-server:latest"
]
}
}
}
For Streamable HTTP, set the transport and start the server:
MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 bun run start:http
# Server listens at http://localhost:3010/mcp
Seed workflows
The repository ships a workflows-yaml/ directory with example workflows organized under categories/. These are ready to use as a starting point. The workflows-yaml/global_instructions.md file contains instructions the server prepends to every workflow_get response — edit it to set global guidance for your agent.
Prerequisites
- Bun v1.4.0 or higher (or Node.js v24+).
- A local directory containing YAML workflow files (or use the bundled
workflows-yaml/seed).
Installation
- Clone the repository:
git clone https://github.com/cyanheads/workflows-mcp-server.git
- Navigate into the directory:
cd workflows-mcp-server
- Install dependencies:
bun install
- Configure environment:
cp .env.example .env
# edit .env if needed — most settings have defaults
Configuration
| Variable | Description | Default |
|---|---|---|
WORKFLOWS_DIR | Absolute or relative path to the workflows root directory. | ./workflows-yaml |
GLOBAL_INSTRUCTIONS_PATH | Path to the global instructions markdown file. Derives from WORKFLOWS_DIR when not set. | <WORKFLOWS_DIR>/global_instructions.md |
WATCHER_DEBOUNCE_MS | Integer milliseconds (0–2147483647) to debounce filesystem change events before rebuilding the index. | 500 |
MCP_TRANSPORT_TYPE | Transport: stdio or http. | stdio |
MCP_HTTP_PORT | Port for HTTP server. | 3010 |
MCP_SESSION_MODE | HTTP sessions: auto or stateful. workflow_delete's confirmation prompt needs a live session, so HTTP startup with stateless fails with a configuration error. Ignored over stdio. | stateful, declared in src/index.ts |
MCP_AUTH_MODE | Auth mode: none, jwt, or oauth. | none |
MCP_REQUEST_STATE_KEY | Seals the requestState a confirmation round carries (≥ 32 bytes, the same on every instance, e.g. openssl rand -base64 32); any state the server did not seal is rejected before the handler runs. workflow_delete's round carries its confirmation id, so set it for HTTP deployments. | unset |
MCP_LOG_LEVEL | Log level (RFC 5424). | info |
LOG_TOOL_FAILURE_PAYLOADS | Log each failed tool call's arguments and result, redacted by key name and capped at LOG_TOOL_FAILURE_PAYLOAD_MAX_BYTES (default 16384). A secret inside a free-form value is not redacted. | false |
OTEL_ENABLED | Enable OpenTelemetry instrumentation (spans, metrics, completion logs). | false |
See .env.example for the full list of optional overrides.
Running the server
Local development
-
Build and run:
# One-time build bun run rebuild # Run the built server bun run start:stdio # or bun run start:http -
Run checks and tests:
bun run devcheck # Lint, format, typecheck, security bun run test # Vitest test suite bun run lint:mcp # Validate MCP definitions against spec
Docker
docker build -t workflows-mcp-server .
docker run --rm \
-v /path/to/workflows-yaml:/workflows-yaml \
-e WORKFLOWS_DIR=/workflows-yaml \
-p 3010:3010 \
workflows-mcp-server
The Dockerfile defaults to HTTP transport, stateful session mode (required — see MCP_SESSION_MODE above), and logs to /var/log/workflows-mcp-server. OpenTelemetry peer dependencies are installed by default — build with --build-arg OTEL_ENABLED=false to omit them.
Project structure
| Directory | Purpose |
|---|---|
src/index.ts | createApp() entry point — registers tools and inits the workflow index service. |
src/config/ | Server-specific environment variable parsing and validation with Zod. |
src/mcp-server/tools/ | Tool definitions (*.tool.ts). |
src/services/workflow-index/ | WorkflowIndexService — YAML parsing, index build, watcher, semver lookup, write helpers. |
tests/ | Unit and integration tests mirroring src/. |
workflows-yaml/ | Seed workflow library — categories/ for permanent workflows, temp/ for temporary drafts, global_instructions.md for agent-global guidance. |
Development guide
See CLAUDE.md for development guidelines and architectural rules. The short version:
- Handlers throw, framework catches — no
try/catchin tool logic - Use
ctx.logfor request-scoped logging - Register new tools via the barrel in
src/mcp-server/tools/definitions/index.ts - Filesystem operations go through
WorkflowIndexService, not directly in tool handlers
Contributing
Issues are welcome. Run checks and tests before submitting:
bun run devcheck
bun run test
License
Apache-2.0 — see LICENSE for details.
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.