Skip to main content
Glama
README.md
# CollabMCP

> Shared, real-time context for every Claude Code on your team — scope awareness, prior decisions, and anti-overlap. No database, no server to host. Just files in your repo.

When two people point Claude Code at the same repo, the agents have no idea the other exists. CollabMCP fixes that: it's a local [MCP](https://modelcontextprotocol.io) server that gives each agent a shared view of who's working on what, what's already been decided, and whether a file is "owned" by someone else right now.

Everything lives in a `.collab/` directory in your repo — plain JSON and a JSONL log. No Postgres, no Redis, no embeddings.

## What you get

Five tools, available to Claude Code automatically:

| Tool | When Claude uses it |
|------|---------------------|
| `get_session` | At the start of a session — who's active, recent decisions, your scope, unread messages |
| `who_owns(path)` | Before editing a file that might belong to a teammate |
| `recall(query)` | Before a big decision — has this already been settled? |
| `remember(content, scope)` | After an architectural decision or non-obvious fix |
| `broadcast(message, urgency)` | To warn the team about a breaking change |

Plus a **dynamic `CLAUDE.md`**: a `<!-- COLLAB -->` block at the top of your `CLAUDE.md` that regenerates automatically as the team's state changes, so every agent reads the latest context.

## Install

CollabMCP is distributed from source (not on npm). Install it once, globally:

```bash
git clone https://github.com/BautistaPessagno/collab-mcp.git
cd collab-mcp
npm install
npm run build
npm link        # makes the `collab-mcp` command available everywhere
```

After `npm link`, `collab-mcp` and `npx collab-mcp` both resolve to your local build.

## Quickstart (5 steps)

> Prerequisite: do the [Install](#install) step once on your machine (clone +
> build + `npm link`). That's what makes the `collab-mcp` / `npx collab-mcp`
> command resolve — the package is not on npm.

```bash
# 1. In your project repo, initialize CollabMCP
npx collab-mcp init

# 2. Set your identity and scope
#    Edit .claude/collab.json: set "dev_id" and the "scope" globs you own
#    e.g. "dev_id": "bautista", "scope": ["/auth/**", "/middleware/**"]

# 3. Restart Claude Code so it loads the MCP server from .claude/mcp.json

# 4. Commit the shared state so teammates get it
git add .collab/state.json .collab/decisions.jsonl .claude/ CLAUDE.md
git commit -m "Add CollabMCP"

# 5. Each teammate does the Install step once (clone + build + npm link),
#    then in this repo runs `npx collab-mcp init`, sets their own
#    dev_id/scope, and restarts Claude Code. Done.
```

Check the team state from the terminal any time:

```bash
npx collab-mcp status
```

## How it works

```
.collab/
├── state.json        # active devs, their scope, current task   (committed)
├── decisions.jsonl   # append-only log of decisions             (committed)
├── locks/            # short-lived path locks                   (gitignored)
└── inbox/            # per-dev broadcast messages               (gitignored)
```

- `who_owns` matches a path against each dev's `scope` globs (via `minimatch`) and any active lock.
- `recall` is keyword-overlap search over `decisions.jsonl` — simple, fast, no embeddings.
- A file watcher regenerates the `CLAUDE.md` block within ~150ms of any state change.
- Writes to `state.json` are atomic (temp file + rename), so concurrent devs don't corrupt it.

## Config (`.claude/collab.json`)

```json
{
  "server": "local",
  "collab_dir": ".collab",
  "dev_id": "bautista",
  "scope": ["/auth/**", "/middleware/**"],
  "lock_ttl_minutes": 30
}
```

## Not in the MVP

Vector search, web dashboard, auth, Postgres/Redis, multi-repo. The data model is intentionally just files — see the roadmap in [`collab_mvp_plan.md`](./collab_mvp_plan.md).

## License

MIT

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: broadcast for messaging, get_session for context snapshot, recall for reading past decisions, remember for writing decisions, who_owns for ownership queries. No overlap.

Naming Consistency3/5

Naming is mixed: 'broadcast', 'recall', 'remember' are single verbs; 'get_session' is verb_noun; 'who_owns' is a question. No consistent pattern, though all are readable.

Tool Count5/5

With 5 tools covering communication, session management, knowledge base, and ownership, the count is well-scoped for a team collaboration server.

Completeness4/5

Covers key collaboration features (messaging, context, decisions, ownership). Minor gap: no explicit lock acquisition/release tool, but get_session and who_owns may suffice.

Maintenance

ActivityInactive
ResponsivenessNo issues