Server-enforced workflow discipline for AI agents: work items, dependency graphs, quality gates
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Server-enforced workflow discipline for AI agents.
Prompt-based frameworks hope the LLM follows instructions. This one blocks the call if it doesn't.
Multi-agent workflows need infrastructure the model doesn't provide. When an orchestrator dispatches sub-agents across sessions, there's no built-in way to enforce what documentation must exist before work starts, track which agent made which change, or guarantee dependency ordering across a work breakdown. These are structural concerns β they belong in the server, not in prompts.
Task Orchestrator is an MCP server β not a prompt layer. It provides 14 tools that give any MCP-compatible AI agent a persistent work item graph with server-enforced quality gates. The enforcement happens at the tool level: if a required design note isn't filled, advance_item returns an error. If a dependency isn't satisfied, the transition is blocked. If actor authentication is enabled and an agent doesn't identify itself, the call is rejected before it reaches the server.
The rules live in the server, not the conversation.
What this means in practice:
| Prompt-Based Frameworks | Task Orchestrator | |
|---|---|---|
| Enforcement | Instructions that agents should follow | Server blocks the call if rules aren't met |
| Persistence | File-based state | SQLite database with structured queries |
| Accountability | No concept of which agent did what | Actor attribution with pluggable verification (JWKS) |
| Dependency ordering | Sequenced by prompt convention | Server validates dependency graphs before allowing transitions |
| Session continuity | Conversation history or file reconstruction | get_context() returns full state in one call |
| Portability | Tied to one AI client | Works with any MCP-compatible client |
Schemas define what agents must produce at each phase β and the server blocks progression until it's done. But schemas do more than gate transitions. They set a planning floor: when an agent enters plan mode, the schema tells it what documentation must exist before implementation can start, shaping the plan structure itself.
advance_item(trigger="start") from queue requires requirements to be filled. No exceptions, no prompt-dependent compliance β the server returns an error with exactly which notes are missing.
The guidance field provides authoring instructions surfaced at the right moment β when the agent is about to fill that note, get_context returns the guidance as a guidancePointer. The skill field takes this further: it references a specific skill that the agent must invoke before filling the note, providing a deterministic evaluation framework rather than freeform prose. Together, they create structured agent behavior that's configured in YAML, not hardcoded in prompts.
Traits add cross-cutting note requirements to any schema without duplicating definitions. Define a trait once, apply it to any item type:
Every feature-task item automatically inherits the security-assessment note requirement. Traits can also be applied per-item via the traits parameter on manage_items β a task touching authentication gets needs-security-review while a CSS cleanup doesn't.
Everything is a WorkItem in a hierarchical graph. Items nest up to 4 levels deep, connected by typed dependency edges. Create an entire work breakdown atomically:
When schema reaches terminal, api is automatically unblocked. When all children complete, the parent cascades to terminal. Dependency ordering is enforced by the server β structurally, not by convention.
Every advance_item transition and manage_notes upsert accepts an optional actor claim:
Enable actor authentication in config to require it:
When enabled, calls without actor claims are blocked before reaching the server. Query responses include the full delegation chain β which orchestrator dispatched which sub-agent, who wrote which note, who made which transition. Post-mortem debugging becomes a data query, not a conversation archaeology exercise.
No context rebuilding. One call recovers the full picture:
Returns active items, recent transitions (with actor attribution), blocked items, stalled items with missing notes, and full ancestor chains. A new session has complete state in a single response.
Notes provide targeted, phase-specific documentation attached to work items. An implementation agent reads a concise requirements note scoped to its task rather than scanning broader project context.
Notes are keyed, role-scoped, and queryable:
Metadata-only queries (includeBody=false) let agents check what exists without paying the token cost of reading every note body.
Search across all work items and notes by keyword. Results are relevance-ranked, so agents surfacing related work or picking up after a long gap get the most relevant matches first β not just a flat list.
Search can be scoped to a subtree, filtered by status or tag, or run across the entire workspace. Agents use this to find related work before starting something new, or to locate a specific note without knowing which item it's attached to.
Task Orchestrator enforces workflow structure without imposing methodology. The server owns the guardrails β role transitions, dependency ordering, gate enforcement, and accountability. Agents own everything else. There are no mandatory planning ceremonies, no prescribed development processes, no opinion on how agents approach implementation. Schemas, traits, and actor authentication are opt-in layers that integrate with your team's development policies through .taskorchestrator/config.yaml. As models gain new capabilities, the harness stays out of the way rather than constraining what agents can do.
Prerequisite: Docker installed and running.
If you work across multiple projects, set up once and every project you open just works: run
one persistent server with the REST API on, and each project's .taskorchestrator/config.yaml syncs
into it automatically via config-sync β no per-project container, no manual config mounting.
Pull the image, then run the plugin's /configure-server skill (or use the equivalent manual setup
below) to stand up a persistent local server:
Register it in .mcp.json (HTTP shape β not an args array):
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/mcp-task-orchestrator)<a href="https://allmcps.com/mcp/mcp-task-orchestrator"><img src="https://allmcps.com/api/badge/mcp-task-orchestrator?style=directory" alt="MCP Task Orchestrator on AllMCPs" /></a>