Labsco
MCP SERVER

MCP IDE Bridge

by Mvp2o-ai ↗

Messaging between IDEs rather than between a client and a tool — one developer's Cursor can hand a task to a teammate's VS Code, or one agent to another.

MCP Plumbing: Proxies, Registries & Inspectors
Summary
Built for a trusted local network, and it says so.

Client ids act as the only credential: there is no authentication beyond them, no message encryption, no access control and no audit log, which the project states plainly rather than leaving you to discover. That makes it a good fit for a local team or a set of agents on one machine, and a poor one for anything crossing an untrusted network. Within those bounds the messaging design is sensible — fire-and-forget plus an explicit collect, so nothing blocks a session waiting on a human.

What it is

A stateless HTTP Streamable MCP server that relays messages between clients. Instead of the usual client-to-server shape, it makes client-to-server-to-client work: each project declares an id and the recipients it may reach, and messages are queued per recipient until they are collected.

What you get
  • Fire-and-forget sending to one or many recipients at once, with a list of messages that can differ per recipient — it returns instantly rather than blocking on a reply — `send_message_without_waiting`
  • Collection of whatever has come back for you, which is the required second half of the pattern — `get_messages`
  • Presence: announce that you are around and what you are working on, and see which connections are currently active — `checkin_client`, `get_active_sessions`
  • A setup helper that reports your configuration back to you when the wiring is not behaving — `get_my_identity`
  • A recipients file per project, naming your own id and the projects you can address, which your IDE's own AI agent can generate for you
  • The same tools for clients that are not IDEs: LangChain, mcp-use and custom apps pass their configuration as a `recipients_config` parameter instead of reading the file, with no registration step and no separate REST surface
Requirements

No account and no key — and that is also the security model, so read the next paragraph before exposing it. The documented path is Docker, publishing port 8111, with the MCP endpoint served over HTTP Streamable; a Python path exists for development, running the messaging module against the same port. Python 3.11+. Each project needs a `mcp_recipients.json` in its root plus whatever MCP configuration its own IDE expects. The project is `mcp-ide-bridge` (1.0.0 in pyproject).

Setup effort

One command — docker run -d --name mcp-ide-bridge -p 8111:8111 mcp-messaging-server