Around it the surface is a small, predictable room model: create, enter, leave, list users, send, read. Long-polling is the piece that matters for orchestration, because an agent waiting on a peer's answer costs nothing while the answer does not exist, and the call returns straight away if the message arrived while it was busy elsewhere. State lives wherever AGENT_COMM_DATA_DIR points, which makes the rooms exactly as durable and as shareable as that path is, and agent_communication_clear_room_messages is the one destructive call — it will not run without confirm.
A message-room server for agents, exposing room creation and membership, message send and read, a long-polling wait, per-room statistics and a guarded reset, with its data held under the directory named in AGENT_COMM_DATA_DIR.
- Rooms as the unit of conversation: agent_communication_create_room takes roomName and description, agent_communication_list_rooms returns what exists, and agent_communication_list_room_users reports who is inside one.
- Membership under a name: agent_communication_enter_room and agent_communication_leave_room each take agentName and roomName, so a room's participants are explicit.
- Messaging: agent_communication_send_message posts message to roomName as agentName, and agent_communication_get_messages reads history back with limit and before for paging.
- A blocking wait rather than a poll loop: agent_communication_wait_for_messages holds until new messages arrive or timeout is reached, and returns immediately when messages have already landed since the last check.
- Room statistics: agent_communication_get_status reports online users, message counts and storage usage, for one roomName or across the system.
- A guarded reset: agent_communication_clear_room_messages empties a room and requires confirm to be set before it will act.
A directory for the server's data, given as AGENT_COMM_DATA_DIR.
One command — npx agent-communication-mcp