mcpField
W
workflows-mcp-server

workflows-mcp-server

Local
github.com/cyanheadsAI & Agents31Updated 3d ago

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

  1. 01List and filter workflows
  2. 02Retrieve versioned definitions
  3. 03Create permanent and temporary YAML
  4. 04Delete after user confirmation
  5. 05Automatic file watching and indexing
  6. 06stdio and Streamable HTTP

Use cases

  1. 01Find a playbook by category or tags
  2. 02Reuse a versioned sequence of MCP calls
  3. 03Draft a workflow before making it permanent
  4. 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.

mcp.json · Universal config
{
"mcpServers": {
"cyanheads-workflows": {
"command": "npx",
"args": [
"-y",
"@cyanheads/workflows-mcp-server"
],
"env": {
"WORKFLOWS_DIR": "<WORKFLOWS_DIR>",
"GLOBAL_INSTRUCTIONS_PATH": "<GLOBAL_INSTRUCTIONS_PATH>",
"WATCHER_DEBOUNCE_MS": "<WATCHER_DEBOUNCE_MS>",
"MCP_LOG_LEVEL": "<MCP_LOG_LEVEL>",
"MCP_TRANSPORT_TYPE": "<MCP_TRANSPORT_TYPE>",
"MCP_HTTP_HOST": "<MCP_HTTP_HOST>",
"MCP_HTTP_PORT": "<MCP_HTTP_PORT>",
"MCP_HTTP_ENDPOINT_PATH": "<MCP_HTTP_ENDPOINT_PATH>",
"MCP_AUTH_MODE": "<MCP_AUTH_MODE>"
}
}
}
}
Run commandnpx -y @cyanheads/workflows-mcp-server
Environment variables to set
WORKFLOWS_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.

Packages
npm@cyanheads/workflows-mcp-server0.4.2

Tools

5

Saved tool list · updated 3d ago

ParameterTypeRequiredDescription
tagsarrayNoFilter 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.
querystringNoKeyword 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.
categorystringNoFilter to workflows whose category contains this string (case-insensitive substring match). Leading and trailing whitespace is ignored. Omit to return all categories.
includeToolsbooleanNoWhen 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.

5 Tools

Version License Docker MCP SDK npm TypeScript Bun

Install in Claude Desktop Install in Cursor Install in VS Code

Framework


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
ToolDescription
workflow_listList all permanent workflows in the index, with optional keyword, category, and tag filters.
workflow_getRetrieve a complete workflow definition by name, with global instructions prepended.
workflow_createWrite a new permanent workflow YAML to the library.
workflow_create_tempWrite a temporary workflow draft, indexed but excluded from list results, kept until deleted.
workflow_deleteRemove 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), and tags (all must match) filters, case-insensitive; temporary drafts are never listed
  • Sorted by name, then highest version first; an empty result carries a notice echoing the applied filters
  • includeTools: true adds each workflow's unique server/tool pairs

workflow_get tool
  • name plus an optional semver version; omit version for the highest available, drafts included
  • Returns the full workflow, its source (permanent or temp), and globalInstructions from global_instructions.md (null when absent); fails with not_found or version_not_found
  • Template placeholders such as {{input.foo}} come back verbatim — the server never interpolates them

workflow_create tool
  • name, semver version, description, author, category, and steps (plus optional tags); stored as one file per name@version under categories/<category>/, with created and updated dates stamped
  • Returns the key (name@version) and filePath; fails with already_exists when a permanent workflow or a draft holds the key, invalid_input, or write_failed

workflow_create_temp tool
  • The workflow_create fields minus category; stored under temp/, retrievable with workflow_get, never listed, and kept until workflow_delete removes it
  • status is created, or overwritten when it replaced the draft of the same key (keeping that draft's created_date); a key held by a permanent workflow fails with already_exists

workflow_delete tool
  • name plus an optional version (omitted: the highest across permanent workflows and drafts); the user confirms the resolved name@version, source, and file before anything is deleted, so a client without elicitation cannot delete
  • Returns the deleted workflow's source, plus a notice when another file declaring the same key now takes its place; fails with cancelled, 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), or not_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/ and temp/ 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, so v1.0.0+build.5 is stored, keyed, and looked up as 1.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.json snapshot is written on every rebuild for external tooling and debugging

Agent-friendly output:

  • Discriminated output — source: "permanent" | "temp" on every workflow_get response and typed reason codes (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_get always returns globalInstructions alongside the workflow definition in the same response
  • Response shaping — workflow_list's optional includeTools flag pre-derives the unique server/tool pairs 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
  1. Clone the repository:
git clone https://github.com/cyanheads/workflows-mcp-server.git
  1. Navigate into the directory:
cd workflows-mcp-server
  1. Install dependencies:
bun install
  1. Configure environment:
cp .env.example .env
# edit .env if needed — most settings have defaults

Configuration

VariableDescriptionDefault
WORKFLOWS_DIRAbsolute or relative path to the workflows root directory../workflows-yaml
GLOBAL_INSTRUCTIONS_PATHPath to the global instructions markdown file. Derives from WORKFLOWS_DIR when not set.<WORKFLOWS_DIR>/global_instructions.md
WATCHER_DEBOUNCE_MSInteger milliseconds (0–2147483647) to debounce filesystem change events before rebuilding the index.500
MCP_TRANSPORT_TYPETransport: stdio or http.stdio
MCP_HTTP_PORTPort for HTTP server.3010
MCP_SESSION_MODEHTTP 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_MODEAuth mode: none, jwt, or oauth.none
MCP_REQUEST_STATE_KEYSeals 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_LEVELLog level (RFC 5424).info
LOG_TOOL_FAILURE_PAYLOADSLog 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_ENABLEDEnable 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

DirectoryPurpose
src/index.tscreateApp() 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/catch in tool logic
  • Use ctx.log for 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

Markdown supported

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.