Runtime-agnostic agent mesh for MCP clients. Shared memory, broadcast channels, task delegation, presence, stable identities, and Tailscale-ready cross-machine coordination. 21 MCP tools, 27 broker routes.
PeerMesh is a multi-agent communication network for MCP-capable clients. Each session registers with a central broker, gets a unique ID and stable session label, and can send direct messages, broadcast to channels, delegate tasks, share persistent memory, and track presence across machines connected via Tailscale.
It started as a heavily extended fork of claude-peers-mcp, then
got generalized so Codex, Claude, Gemini, and other MCP clients can all speak
the same mesh instead of carrying Claude-specific assumptions in the core.
MCP client A MCP client B MCP client C
| | |
[ server.ts ] [ server.ts ] [ server.ts ]
\___________________________|___________________________/
|
[ Broker (Bun) ]
|
[ SQLite WAL ]
peers, messages, memory, channels, tasks
The broker is a Bun HTTP server exposing 27 POST routes plus a health endpoint. Each client runs a stdio MCP server that polls the broker for incoming work. No WebSockets, no long-polling complexity. Just clean request/response with bearer token auth, SQLite WAL mode, and transport that works both locally and over Tailscale.
Agent-A > send_message(to: "agent-b", body: "Run tests on the crawler module")
Broker: stored, pending delivery
Agent-B > check_messages()
Broker: [{from: "agent-a", body: "Run tests on the crawler module"}]
Agent-B > send_message(to: "agent-a", body: "All 47 tests pass. 0 failures.")
Broker: stored, pending delivery
Agent-A > check_messages()
Broker: [{from: "agent-b", body: "All 47 tests pass. 0 failures."}]
Built with TypeScript, Bun, and SQLite. The current version is the cleaned-up, generic PeerMesh pass: dynamic identity, filtered inboxes, remote/local peer awareness, smoke tests, and cross-client setup examples.