Transport Layer

MCP supports two transport mechanisms: stdio for local servers and Streamable HTTP for remote servers. The transport choice determines how the MCP client and server communicate — and it matters more than most people think. Getting the transport wrong is the number one reason MCP setups fail on first attempt.

Stdio transport is the simplest and most common. The MCP client starts the server as a child process on the local machine. Communication happens through standard input and standard output — the client writes JSON-RPC messages to the server's stdin, the server writes responses to its stdout. No network. No ports. No TLS. No authentication. The operating system handles the pipe. This is why most MCP servers "just work" locally — there is nothing to configure beyond the command to start the server.

Streamable HTTP is the remote transport. The server exposes an HTTP endpoint, and the client connects to it over the network. This transport supports session management, authentication (via OAuth 2.0), and the ability for servers to push messages to clients using Server-Sent Events (SSE). Streamable HTTP replaced the older SSE-only transport in the 2025 spec revision, combining the request-response pattern of HTTP POST with the server-push capability of SSE into a single, cleaner protocol.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/documents"]
    },
    "remote-db": {
      "url": "https://mcp.example.com/db",
      "headers": {
        "Authorization": "Bearer ${MCP_DB_TOKEN}"
      }
    }
  }
}