MCP Task Orchestrator
Wire an MCP server into Claude Code or Cursor so your coding agent must follow work-item queues, dependency order, and quality gates instead of free-form guessing.
Overview
MCP Task Orchestrator is a MCP server for the Build phase that enforces work items, dependency graphs, and quality gates so AI coding agents follow your workflow instead of improvising.
What is this MCP server?
- Persists work items in SQLite with configurable DATABASE_PATH and optional Flyway migrations
- Models dependency graphs so agents cannot silently skip blocked or out-of-order tasks
- Enforces quality gates via server-side workflow schemas from .taskorchestrator/config.yaml
- Runs as stdio MCP (default) or HTTP on MCP_HTTP_PORT for remote setups
- Ships as OCI image ghcr.io/jpicklyk/task-orchestrator:latest for repeatable installs
- Server version 3.2.0 per MCP registry schema
- Default transport stdio; optional HTTP via MCP_TRANSPORT and MCP_HTTP_PORT (default 3001)
- SQLite storage with USE_FLYWAY default true for database migrations
Community signal: 193 GitHub stars.
What problem does it solve?
Agents often jump ahead, forget prerequisites, or claim work is finished without meeting your definition of done.
Who is it for?
Solo builders running multi-step agent implementation on one codebase who want SQLite-backed task state and YAML-defined gates without a separate PM app.
Skip if: Teams that only need a one-shot code snippet or a single REST integration with no ongoing work-item lifecycle.
What do I get? / Deliverables
After you add the server to your agent, tasks stay ordered, blocked items surface clearly, and gates must pass before the workflow advances.
- Persisted work items and dependency relationships in a local task database
- Server-enforced advancement only after configured quality gates succeed
- Project-specific workflow schemas driven from task orchestrator YAML config
Recommended MCP Servers
Journey fit
Task orchestration sits where solo builders actually run agents on real features: after validation, during implementation. The catalog shelves it under Build because that is when multi-step agent work needs structure, even though gates also matter in Ship. Agent-tooling is the right subphase for stdio MCP servers that change how the agent plans and executes work, rather than calling a single external API.
How it compares
MCP workflow enforcement with persisted graphs, not a passive documentation skill or a generic chat checklist.
Common Questions / FAQ
Who is MCP Task Orchestrator for?
It is for indie and solo developers using MCP-enabled coding agents who need structured work items, dependencies, and quality gates on real build work.
When should I use MCP Task Orchestrator?
Use it when agent sessions span many steps, order matters, and you want the server—not the model—to block progress until configured gates pass.
How do I add MCP Task Orchestrator to my agent?
Register the OCI package ghcr.io/jpicklyk/task-orchestrator:latest with stdio transport, set DATABASE_PATH and AGENT_CONFIG_DIR if needed, and point your agent’s MCP config at the server.