workflows-mcp-server

Tools

Five tools covering the full workflow library lifecycle — discovery, retrieval, creation, and deletion for both permanent and temporary workflows:

`workflow_list`

List permanent workflows from the in-memory index.

• Optional keyword `query` filter (case-insensitive substring across workflow name and description)
• Optional category filter (case-insensitive substring match)
• Optional tag filter (AND match — all listed tags must be present)
• Set `includeTools: true` to surface the unique `server/tool` pairs used across each workflow's steps
• Temporary workflows are excluded; results sorted by name then version descending
• Empty results echo the applied filters with a hint to broaden

`workflow_get`

Retrieve a complete workflow by name, including the global instructions document.

• Semver-aware: omit `version` to get the highest available match; specify a version for an exact lookup
• Returns the full workflow YAML structure with all steps and metadata
• Injects the `global_instructions.md` content as `globalInstructions` — apply these when executing the workflow; `null` when the file is absent
• Temporary workflows are accessible here even though excluded from `workflow_list`
• Template placeholders (`{{input.foo}}`, `{{steps.X.output.Y}}`) are returned verbatim — the server never interpolates them

`workflow_create`

Write a new permanent workflow to the library.

• Workflow stored at `categories//--workflow.yaml` — one file per `name@version`, so multiple versions coexist
• Rejects if `name@version` already exists — bump the version to create a new revision
• Server stamps `created_date` and `last_updated_date` automatically
• Index and snapshot rebuilt after write; filesystem watcher also fires (idempotent, debounced)

`workflow_create_temp`

Write a throwaway workflow to the `temp/` directory.

• No conflict check — temp workflows are intentionally ephemeral and overwriteable
• Indexed and accessible via `workflow_get` but excluded from `workflow_list` results
• Useful for one-shot plans, short-lived scaffolding, or session-specific orchestration steps

`workflow_delete`

Permanently remove a permanent workflow from the library.

• Semver-aware: omit `version` to delete the highest available match; specify a version to target one exactly
• Only permanent workflows can be deleted — temporary workflows are rejected (they expire on their own)
• Irreversible: the file is removed and the workflow no longer appears in `workflow_list` or `workflow_get`

Features

Built on `@cyanheads/mcp-ts-core`:

• Declarative tool definitions — single file per primitive, framework handles registration and validation
• Unified error handling — handlers throw, framework catches, classifies, and formats
• Pluggable auth: `none`, `jwt`, `oauth`
• Swappable storage backends: `in-memory`, `filesystem`, `Supabase`, `Cloudflare KV/R2/D1`
• Structured logging with optional OpenTelemetry tracing
• STDIO and Streamable HTTP transports

Workflow library:

• In-memory index keyed by `name@version`, built at startup from `workflows-yaml/categories/` recursively
• Semver-aware lookup — latest version returned when version is omitted
• Filesystem watcher (Node.js `fs.watch` recursive) rebuilds the index on any add/change/remove; debounced to avoid thrash
• YAML validated at index time — invalid files are skipped and logged, never crash the server
• `_index.json` snapshot written on every rebuild for external tooling and debugging
• Configurable `WORKFLOWS_DIR`, `GLOBAL_INSTRUCTIONS_PATH`, and debounce interval

Agent-friendly output:

• `workflow_get` always includes `globalInstructions` alongside the workflow — no second call needed
• Discriminated `source` field (`permanent` | `temp`) on every `workflow_get` response
• Typed error contracts with structured `reason` codes (`not_found`, `version_not_found`, `already_exists`, `temp_not_allowed`, `index_unavailable`) so callers can branch on error type rather than parsing messages
• `workflow_list` with `includeTools: true` surfaces all MCP server/tool dependencies at a glance

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.3.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

2. Navigate into the directory:

cd workflows-mcp-server

3. Install dependencies:

bun install

4. Configure environment:

cp .env.example .env
# edit .env if needed — most settings have defaults

Configuration

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, stateless session mode, 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

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 and pull requests are welcome. Run checks and tests before submitting:

bun run devcheck
bun run test

License

Apache-2.0 — see LICENSE for details.