Pi Conductor
Related Servers
Alternatives to Pi Conductor
No user-submitted related servers found.
Related Servers
- 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.5 npm4MIT
- 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.2 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.108 npmMIT
- AlicenseAqualityAmaintenanceLocal-first multi-agent delegation and approval control for Codex via MCP, with persistent task DAG, isolated worktrees, and a web console.141MIT
- AlicenseNot gradedqualityCmaintenanceEnables Codex to delegate bounded coding tasks to MiMo Code through a shared local daemon, supporting task boundaries, Git Worktrees, and a collaborative review workflow.3MIT
- FlicenseNot gradedqualityBmaintenanceEnables Codex to delegate bounded tasks to multiple AI model workers through a persistent OpenCode 2 service, with isolated Git worktrees and safe patch review and application.-
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.