MCP Advanced: STDIO Transport, Connection Handshake, Bidirectional Communication

The STDIO transport is the most commonly used transport for local MCP development. The client launches the MCP server as a subprocess and communicates through standard input and output streams. The client sends messages to the server using the server's stdin, and the server responds by writing to stdout. Either party can send a message at any time, making it truly bidirectional. The main limitation is that both client and server must run on the same machine since they share a process pipe. This transport is ideal for development and testing.

Every MCP connection must begin with a specific three-message handshake before any other communication can occur. First, the client sends an Initialize Request. Second, the server responds with an Initialize Result that includes its capabilities, describing which features like tools, resources, and prompts it supports. Third, the client sends an Initialized Notification confirming it has processed the server's capabilities. Only after this handshake completes can you send requests like tool calls, prompt listings, or resource reads. Skipping this sequence causes the server to reject requests.

You can test an MCP server by running it with a command like uv run server.py, which makes it listen on stdin and write responses to stdout. You can then paste JSON messages directly into your terminal and see the server's responses immediately. Start with the initialization handshake messages, then send tool call or list requests. The terminal output shows the complete message exchange in raw JSON format. This technique is useful for debugging message formats and verifying that your server handles requests correctly before building a full client.

Any MCP transport must handle four communication patterns. Client to server request, where the client initiates a call like listing tools or calling a function. Server to client response, where the server returns the result of that request. Server to client request, where the server initiates communication like asking the client to call Claude through sampling. Client to server response, where the client returns the result of the server's request. The STDIO transport handles all four naturally because either party can write to the pipe at any time without restrictions.

STDIO represents the ideal case where bidirectional communication is completely seamless. Both client and server can initiate messages at any time using stdin and stdout, with no restrictions on direction or timing. This makes all MCP features work perfectly including sampling, notifications, progress reports, and roots. When you move to HTTP transports, the server cannot always initiate requests to the client. Understanding STDIO as the full-capability baseline helps you recognize what gets lost with other transport methods.

The primary limitation is that both client and server must run on the same machine because they communicate through process pipes. You cannot use STDIO to connect to a remote MCP server hosted in the cloud or on another computer. This makes STDIO unsuitable for production deployments where the server needs to be publicly accessible or shared across multiple clients on different machines. For those scenarios, you need the StreamableHTTP transport, which introduces its own set of trade-offs around server-to-client communication capabilities. ---