Pi Conductor
Related Servers
Alternatives to Pi Conductor
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceEnables Codex to supervise one or more local Pi coding-agent workers through bounded task execution, state polling, steering, aborting, and listing. Tasks can run in a direct working directory or isolated Git worktree while Codex remains the planner and reviewer.MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server for orchestrating a fleet of CLI coding agents in isolated git worktrees. It exposes tools for spawning workers, sending instructions, reviewing diffs, and merging changes, with full terminal visibility.6 npm4MIT
- AlicenseNot gradedqualityAmaintenanceEnables a primary agent to dispatch, wait on, and supervise multiple parallel Codex CLI workers, each running in its own isolated Git worktree with conflict-checked path ownership. Persists every worker's state, goals, and event stream to disk so work can be tracked, resumed, reconnected, searched, and cancelled across restarts.1,657 npm3MIT
- AlicenseAqualityBmaintenanceEnables Claude Code or any MCP client to delegate hands-on coding work to OpenAI Codex over a persistent app-server process, keeping long-lived threads with follow-ups, async polling, approvals, steering, and interrupts. Supports native code review, resuming existing sessions, structured output, and parallel worktree-isolated tasks.1024 npm1MIT
- FlicenseNot gradedqualityBmaintenanceEnables MCP hosts like Claude Code and Codex to spawn, manage, and interact with persistent, reusable Pi coding-agent sessions, supporting task dispatch, status checks, and session lifecycle control.3 npm-
- AlicenseAqualityBmaintenanceEnables supervising and orchestrating local coding agents like Muse and AGY through a client-agnostic MCP interface, with isolated Git worktrees, safe execution, and deterministic verification.107 npmMIT
TDQS
Scored across 13 tools
Most tools have a clearly distinct lifecycle role (spawn, kill, merge, cleanup, send). There is mild overlap in reporting: pi_wait, pi_digest, and pi_status all surface worker state/digests, though the blocking-vs-snapshot distinction is described well enough to disambiguate.
Every tool uses a uniform pi_ prefix with a short, readable suffix. Action verbs (spawn, wait, send, kill, merge, cleanup) and config nouns (dict, tools, model, effort, status) are used consistently within their categories.
13 tools is well-scoped for a worker-orchestration server, covering the full lifecycle without redundant entries. Each tool earns its place (lifecycle ops, config, and two project-context stores).
The surface covers the whole worker lifecycle: spawn, monitor (wait/digest/status), review (diff), follow-up (send), abort (kill), integrate (merge), and teardown (cleanup), plus model/effort config and shared project context. No obvious gaps or dead ends.