Agent Comms logo

Agent Comms

Connects MCP-based agents through TCP for rooms, direct messages, presence, discovery, and delivery of missed events.

Install Agent Comms

Pick your client, then add it in one click or paste the config.

STDIONode.js
~/Library/Application Support/Claude/claude_desktop_config.json
claude_desktop_config.json
{
  "mcpServers": {
    "agent-comms": {
      "command": "npx",
      "args": [
        "-y",
        "agent-comms"
      ]
    }
  }
}

Settings → Developer → Edit Config, merge this into mcpServers, then fully quit and reopen Claude Desktop.

Automated check passed— started and listed 1 tools correctly (14d ago).

Overview

Agent Comms MCP server connects agent processes across harnesses through an in-memory TCP mesh on localhost. Agents can register, discover peers, join rooms, send direct messages, and expose presence or visibility information. Peer bridges synchronize state directly, while queued delivery events are replayed when a process returns. Reach for it when agents running in separate sessions need to coordinate without shared files, polling, or a separate daemon.

Use cases

  • Coordinate agents running in separate local harnesses
  • Send review requests between Claude Code and Codex sessions
  • Organize collaborating agents into rooms
  • Deliver messages queued while an agent restarts

Key features

  • TCP peer mesh on localhost
  • Agent registration and discovery
  • Rooms and direct messages
  • Presence and visibility
  • Replicated delivery queues
  • UDP-based peer discovery

Tools1

What Agent Comms lets your agent do. Expand a tool for its parameters.

Verified live~640 tokens of context

Security & health

What it can reach and how reliably it runs — from our own checks, not the maintainer’s claims.

ActiveLast checked 1d ago

Recent health check succeeded.

13/13 checks healthy over the last 90d

What it can do

From the 1 tool this server returned when we ran it.

Read-only tools · 1
Network at startup4 connections
Files written at startup4
Install scriptsprepare
npm provenanceSigned build
Package age181 days
Maintainers1

Observed 2026-10-25 in an isolated sandbox. A description of reach, not a security audit.

Supply-chain signal

No high-severity advisories surfaced by our automated scan.

Critical 0High 0Medium 0Low 0

Scanned 2d ago via OSV.dev · agent-comms (npm)

Adoption & maintenance

Factual signals from GitHub, npm, and our automated checks — not a rating.

GitHub stars36Stargazers on the source repository.
npm downloads11kPackage downloads in the last 30 days.
Last commit4d agoMost recent push to the default branch.
Availability100%Our rolling endpoint + install checks that succeeded.
Install checkPassedOur sandbox started it and listed its tools.
Tools exposed1Callable tools this server registers over MCP.
Directory activity3 viewsConfig copies, upvotes, and views on AllMCPs.

How Agent Comms works

What Agent Comms MCP server does

Agent Comms MCP server provides a communication layer for agents running in different harnesses. It addresses the isolation between sessions such as Claude Code, Codex, and pi by allowing each bridge to register with the mesh and locate other active agents.

The supported communication model includes rooms, direct messages, agent presence, and visibility. An agent can use the communication interface to send messages to another agent or participate in shared coordination. The implementation keeps communication state in memory rather than writing JSON files to a shared directory.

How it works

Each MCP bridge acts as a peer in a TCP mesh. The first process normally binds localhost port 19876 and introduces later peers, but that listener is only a first-contact mechanism; it is not a message router. After discovery, peers establish direct data connections with one another, so messages do not depend on a central forwarding process.

Peer discovery also uses UDP port 19877. Bridges send a startup probe and periodic beacons, with multicast on the loopback interface and limited broadcast used for discovery. A bridge that receives a beacon connects directly to the advertised data port. Peer lists are shared across established connections, allowing the mesh to form transitively.

State is replicated across peers. Delivery events that accumulate while an agent process is offline remain in replicated queues and are delivered when its bridge reconnects. This allows a returning process to receive missed events instead of having to inspect history manually.

The mesh elects a coordinator for machine-local housekeeping. That role handles stale-agent PID checks, departure announcements, and the default cc-peer front for local Claude Code sessions without their own bridge. The coordinator role is distinct from ownership of port 19876 and can move to another peer after a departure.

Tools and capabilities

The material identifies an agent_comms interface with a send operation and describes these communication capabilities:

  • Register an agent with the mesh.
  • Discover other registered agents.
  • Join communication rooms.
  • Send direct messages.
  • Publish or inspect presence and visibility information.
  • Deliver queued events after a bridge restarts.

Setup and configuration

Bridges communicate over localhost TCP and use port 19876 for first contact. UDP port 19877 carries discovery beacons and probes. The UDP multicast group is 239.255.19.77; limited broadcast provides a fallback when loopback multicast is unavailable.

The design requires no filesystem bus and no standalone daemon. Each running MCP bridge participates in the mesh as its own process.

Limitations and notes

The coordinator's duties are scoped to peers on the same machine and are accepted only over trusted loopback sessions. Claims received from potentially cross-machine sessions are not used for coordinator decisions.

A coordinator vacancy briefly pauses stale-agent probing and the local cc-peer front until a successor claims the role. Existing peer data connections remain active during port-holder failure, so surviving peers can continue exchanging messages while first contact is restored.

The design uses in-memory replicated state, so its delivery behavior depends on the participating bridge processes and their peer connections.

Reviews

No reviews yet — be the first to share how it worked for you.

Frequently Asked Questions about Agent Comms

Agent Comms is an MCP server that connects agents across Claude Code, Codex, pi, and other harnesses through a local TCP mesh. Its main tools and capabilities support agent registration, peer discovery, rooms, direct messages, presence, visibility, and delivery of events queued while a bridge is offline.

It connects agents through direct TCP peer connections between their MCP bridge processes. Port 19876 provides first contact, while UDP port 19877 uses multicast and broadcast beacons to discover peers and advertise data ports.

No, Agent Comms does not require a shared filesystem or standalone daemon. Each MCP bridge is a running peer, and communication state is held in memory and synchronized across the TCP mesh.

Messages are retained in replicated delivery queues and replayed when the agent's bridge returns. The restarted bridge is notified of events it missed rather than needing to find them only in message history.

Related MCP servers

Add a badge to your READMEShow it’s listed — live SVG, Markdown or HTML.

AllMCPs Directory Badge

Full Badge Customizer

Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.

Badge Style:
Live Dynamic SVG PreviewAgent Comms AllMCPs Directory Badge
Markdown (GitHub README)
[![AllMCPs](https://allmcps.com/api/badge/agent-comms?style=directory)](https://allmcps.com/mcp/agent-comms)
HTML Embed
<a href="https://allmcps.com/mcp/agent-comms"><img src="https://allmcps.com/api/badge/agent-comms?style=directory" alt="Agent Comms on AllMCPs" /></a>