We built the first NeuroLink MCP server manager to run external tools as subprocesses, communicating over stdio. It was simple, self-contained, and it worked perfectly for tools that were packaged with the main application. Then we deployed a new tool at Juspay, a Python-based document analyzer running in its own Docker container. The stdio transport failed instantly. The parent NeuroLink process couldn't spawn a process inside a separate container, and even if it could, we had no way to monitor the tool's health, manage its lifecycle, or scale it independently. That failure forced us to decouple the tool from the agent, leading to the four-transport architecture MCP uses today: stdio for simple cases, and HTTP, Server-Sent Events (SSE), and WebSockets for robust, networked tool execution.
The Problem with Tight Coupling
The original MCP transport, stdio, treats a tool like a command-line utility. When you register a server with this transport, the ExternalServerManager spawns the tool's process and attaches to its stdin, stdout, and stderr streams.
This is a valid approach for simple, co-located tools. For example, a small Node.js script that lives on the same machine as the NeuroLink agent.
