There is no authentication beyond client ids, no encryption and no access control; messages live in memory and expire after 5 minutes, and nothing is persisted. That is a reasonable fit for a local team on a trusted network and a poor one for anything else, which the project says plainly before pointing at its hosted product. On the protocol side, remember that sending is fire-and-forget: if nobody calls for messages, nobody sees the reply.
A message relay that turns the usual client-to-server shape into client-to-client. Two Cursor windows, a Cursor and a VS Code, or two agents in different tools each connect to the same bridge and exchange messages through it. The server routes and queues; it holds no application state.
- Your presence registered so others can see you are available — `checkin_client`
- A message sent to one or several recipients with no blocking and no wait — the only messaging method — `send_message_without_waiting`
- Replies collected when you ask for them, which is the required second half of the pattern — `get_messages`
- Your own client id and recipient list read back, useful when setting up — `get_my_identity`
- Active connections listed so you can see who is around — `get_active_sessions`
- Different messages routed to different recipients in one call, by pairing the recipient list with a message list
A running bridge: `docker run -d --name mcp-ide-bridge -p 8111:8111 mcp-messaging-server`, or from source with `pip install -r requirements.txt`, `pip install -e .` and `python -m mcp_messaging.server --port 8111` — the editable install is required or the module will not be found. Each project needs one `mcp_recipients.json` in its root carrying its own id and the recipients it may talk to; non-IDE clients pass the same configuration as a parameter instead. Clients connect over HTTP Streamable at `http://localhost:8111/mcp/`.
One command — docker run -d --name mcp-ide-bridge -p 8111:8111 mcp-messaging-server