Happy slice of mcp pizzaMCP.pizza

task-orchestrator

MCP.Pizza Chef: jpicklyk

Work items, the order they have to happen in, and the notes behind them live in a small database on your machine instead of in a chat history, so an assistant can pick up exactly where the last one stopped. Rules you write decide what must be filled in before a task moves forward, and the step is refused when something is missing. Every note and status change records which assistant made it. Setup is technical, and it works with any assistant that supports this kind of connection.

Coding
Notes

Use This MCP server To

Pick up a long project where the last session stopped Keep tasks from starting before their prerequisites are done Require a written plan before any work item advances See which assistant made each change and when Break a big project into linked tasks in one go Get the full state of my project back instantly

README

MCP Task Orchestrator

Server-enforced workflow discipline for AI agents.

Prompt-based frameworks hope the LLM follows instructions. This one blocks the call if it doesn't.

Version CI License: MIT MCP Compatible

The Problem

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.

A Different Approach

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:

  • An agent can't start implementation without filling the required specification note
  • A sub-agent can't advance a blocked task until its upstream dependency is complete
  • Every transition and note records who made the change (actor attribution)
  • Auditing mode blocks any write operation where the agent doesn't identify itself
  • A new session picks up exactly where the last one left off — persistent state, not conversation replay
  • Workflow schemas are YAML config, not hardcoded prompts — change the rules without changing code

How It's Different

task-orchestrator FAQ

Which apps does it work in?
Any assistant that supports this kind of connection. It is deliberately not tied to a single client.
Do I need an account or key?
No account is needed. Everything is stored in a local database file on your own machine.
How hard is setup?
Technical. Expect a container or local install plus a configuration file where your rules live.
Can I use this to stop several agents tripping over each other?
Yes, a task stays blocked until the work it depends on finishes, and every change is attributed to whoever made it.
Where does my project data live?
In a local database file, not in anyone's cloud service.
Do I have to write code to change the rules?
No, the rules sit in a plain configuration file you can edit directly.