claude-teams (cs50victor) — Summary

An MCP server that reimplements Claude Code's internal "agent teams" protocol as a standalone, portable MCP tool set. Claude Code has a built-in agent teams feature (shared task lists, inter-agent messaging, tmux-based spawning), but the protocol is internal and tightly coupled to Claude Code's own tooling. This server makes that same protocol available to any MCP client — Claude Code, OpenCode, or anything that speaks MCP.

The server provides 12 MCP tools for team lifecycle management: creating teams, spawning teammates in tmux panes/windows, sending/receiving messages between agents, managing a shared task list, and handling graceful shutdown coordination. State is persisted to ~/.claude/teams/ and ~/.claude/tasks/ as JSON files with atomic writes.

Built by cs50victor (GitHub), based on a deep dive into Claude Code's internals. The implementation is Python (FastMCP framework), requires Python 3.12+, tmux, and at least one coding agent (claude or opencode) on PATH. With 271 stars, this is the highest-starred framework in this batch. Compared to seeds: closest to claude-flow (Archetype 3 — MCP server for multi-agent orchestration) but claude-flow uses its own hive-mind protocol while claude-teams reimplements Claude Code's existing native teams protocol for portability.

claude-teams (cs50victor) — Overview

Origin

Created by cs50victor (GitHub), version 0.1.1 (pinned in README). Based on a "deep dive into Claude Code's internals" (linked gist: https://gist.github.com/cs50victor/0a7081e6824c135b4bdc28b566e1c719). The stated goal: make Claude Code's agent teams feature available to any MCP client, not just Claude Code itself.

Philosophy

"Claude Code has a built-in agent teams feature (shared task lists, inter-agent messaging, tmux-based spawning), but the protocol is internal and tightly coupled to its own tooling. This MCP server reimplements that protocol as a standalone MCP server, making it available to any MCP client."

The philosophy is "open protocol, closed platform" — Claude Code has powerful multi-agent coordination built in, but it's not accessible from OpenCode, Cursor, or other agents. This server standardizes it.

Architecture Style (from README)

• Spawning: Teammates launch in tmux panes (default) or windows (USE_TMUX_WINDOWS)
• Messaging: JSON inboxes at ~/.claude/teams/<team>/inboxes/
• Tasks: JSON files at ~/.claude/tasks/<team>/
• Concurrency: Atomic writes via tempfile + os.replace, cross-platform file locks via filelock

State Filesystem Layout

~/.claude/
├── teams/<team>/
│   ├── config.json
│   └── inboxes/
│       ├── team-lead.json
│       ├── worker-1.json
│       └── .lock
└── tasks/<team>/
    ├── 1.json
    ├── 2.json
    └── .lock

Supported Backends

• claude (Claude Code CLI)
• opencode (OpenCode agent)

claude-teams — Architecture

Distribution

mcp-server — Python package installable via uvx (recommended) or pip.

Install

Claude Code (.mcp.json):

{
  "mcpServers": {
    "claude-teams": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/cs50victor/claude-code-teams-mcp@v0.1.1", "claude-teams"]
    }
  }
}

OpenCode (~/.config/opencode/opencode.json):

{
  "mcp": {
    "claude-teams": {
      "type": "local",
      "command": ["uvx", "--from", "git+https://...", "claude-teams"],
      "enabled": true
    }
  }
}

Source Tree

src/claude_teams/
├── __init__.py
├── _filelock.py          # Cross-platform file locking
├── messaging.py          # Inbox read/write operations
├── models.py             # Pydantic data models
├── opencode_client.py    # OpenCode HTTP API client
├── server.py             # FastMCP server (tool definitions)
├── spawner.py            # tmux pane/window spawning
├── tasks.py              # Task CRUD operations
├── teams.py              # Team lifecycle management
└── tmux_introspection.py # Read tmux pane content

State Storage

~/.claude/teams/<team>/
  ├── config.json          # Team config + member list
  └── inboxes/
      ├── <agent-id>.json  # Per-agent message queue
      └── .lock            # filelock
~/.claude/tasks/<team>/
  ├── <task-id>.json       # Task with status/owner/deps
  └── .lock

Runtime Requirements

• Python 3.12+
• tmux (for spawning subagents)
• claude CLI on PATH (for Claude Code teammates)
• opencode CLI on PATH (for OpenCode teammates)
• OPENCODE_SERVER_URL env var (for OpenCode HTTP API integration)

Environment Variables

claude-teams — Components

MCP Tools (12)

Message Types (send_message)

• DM: Direct message to a specific teammate
• Broadcast: Lead-only; sent to all teammates
• Shutdown: Request graceful shutdown
• Plan response: Teammate responds to a plan from lead

Task Status Values

Tasks have status tracking, ownership, and dependency management. Status values not enumerated in surface README but task_update supports status, owner, dependencies, and metadata updates.

Scripts (0)

None.

Skills (0)

None.

Hooks (0)

None.

Configuration (0 config files)

No framework config files — all configuration is via environment variables and .mcp.json.

claude-teams — Uniqueness

differs_from_seeds

Closest seed is claude-flow (Archetype 3 — MCP-based multi-agent orchestration with hive-mind protocol). Key difference: claude-flow invents its own multi-agent coordination protocol with RAFT-like consensus; claude-teams reverse-engineers and reimplements Claude Code's existing native protocol to make it available to other agents. superpowers also does multi-agent (via task-tool spawning) but as skills, not MCP tools. None of the 11 seeds use tmux-pane isolation combined with file-based messaging.

Positioning

claude-teams occupies a unique niche: it is the only framework that aims to be protocol-compatible with Claude Code's native agent teams feature rather than inventing a parallel system. A team created with claude-teams should be observable/manageable with Claude Code's native teams UI (if such a UI existed).

Distinctive Opinion

"Claude Code has a built-in agent teams feature... but the protocol is internal and tightly coupled to its own tooling."

The framework argues that AI agent coordination protocols should be open and portable, not vendor-locked. By reimplementing the protocol as a standalone MCP server, it enables cross-agent team management.

Observable Failure Modes

1. tmux dependency: No tmux = no agent spawning. This is a hard requirement unusual in the ecosystem
2. Inbox message accumulation: Messages persist until manually cleared; long-running teams accumulate large inbox files
3. Asymmetric messaging: Workers cannot coordinate peer-to-peer — all communication goes through the lead, creating a single point of coordination overhead
4. "Pin to release tag" warning: README explicitly warns against using main branch: "There are breaking changes between releases" — indicates instability
5. OPENCODE_SERVER_URL required for OpenCode: OpenCode teammates require a running OpenCode HTTP server, adding setup complexity
6. Concurrency risk: The _lifespan_state dict comment in server.py notes: "Safe under stdio (single session). Racy under SSE/streamable HTTP" — concurrent sessions are not fully supported

What Makes It Novel vs. the 11 Seeds

• Only framework that reverse-engineers and reimplements an existing agent protocol (Claude Code's teams)
• Only MCP server using tmux-pane isolation for agent spawning
• Only framework supporting cross-agent coordination between Claude Code and OpenCode teammates
• Only multi-agent framework where workers are explicitly restricted from peer-to-peer messaging
• Highest stars (271) in this batch