MCP Transport Mechanisms

​

STDIO Transport

​

How STDIO Transport Works

1. The client (Sixth) spawns an MCP server as a child process
2. Communication happens through process streams: client writes to server’s STDIN, server responds to STDOUT
3. Each message is delimited by a newline character
4. Messages are formatted as JSON-RPC 2.0

Client                    Server
  |                         |
  |<---- JSON message ----->| (via STDIN)
  |                         | (processes request)
  |<---- JSON message ------| (via STDOUT)
  |                         |

​

STDIO Characteristics

• Locality: Runs on the same machine as Sixth
• Performance: Very low latency and overhead (no network stack involved)
• Simplicity: Direct process communication without network configuration
• Relationship: One-to-one relationship between client and server
• Security: Inherently more secure as no network exposure

​

When to Use STDIO

• Local integrations and tools running on the same machine
• Security-sensitive operations
• Low-latency requirements
• Single-client scenarios (one Sixth instance per server)
• Command-line tools or IDE extensions

​

STDIO Implementation Example

import { Server } from "@modelcontextprotocol/sdk/server/index.js"
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"

const server = new Server({ name: "local-server", version: "1.0.0" })
// Register tools...

// Use STDIO transport
const transport = new StdioServerTransport(server)
transport.listen()

​

SSE Transport

​

How SSE Transport Works

1. The client (Sixth) connects to the server’s SSE endpoint via HTTP GET request
2. This establishes a persistent connection where the server can push events to the client
3. For client-to-server communication, the client makes HTTP POST requests to a separate endpoint
4. Communication happens over two channels:
   • Event Stream (GET): Server-to-client updates
   • Message Endpoint (POST): Client-to-server requests

Client                             Server
  |                                  |
  |---- HTTP GET /events ----------->| (establish SSE connection)
  |<---- SSE event stream -----------| (persistent connection)
  |                                  |
  |---- HTTP POST /message --------->| (client request)
  |<---- SSE event with response ----| (server response)
  |                                  |

​

SSE Characteristics

• Remote Access: Can be hosted on a different machine from your Sixth instance
• Scalability: Can handle multiple client connections concurrently
• Protocol: Works over standard HTTP (no special protocols needed)
• Persistence: Maintains a persistent connection for server-to-client messages
• Authentication: Can use standard HTTP authentication mechanisms

​

When to Use SSE

• Remote access across networks
• Multi-client scenarios
• Public services
• Centralized tools that many users need to access
• Integration with web services

​

SSE Implementation Example

import { Server } from "@modelcontextprotocol/sdk/server/index.js"
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js"
import express from "express"

const app = express()
const server = new Server({ name: "remote-server", version: "1.0.0" })
// Register tools...

// Use SSE transport
const transport = new SSEServerTransport(server)
app.use("/mcp", transport.requestHandler())
app.listen(3000, () => {
	console.log("MCP server listening on port 3000")
})

​

Local vs. Hosted: Deployment Aspects

​

STDIO: Local Deployment Model

• Installation: The server executable must be installed on each user’s machine
• Distribution: You need to provide installation packages for different operating systems
• Updates: Each instance must be updated separately
• Resources: Uses the local machine’s CPU, memory, and disk
• Access Control: Relies on the local machine’s filesystem permissions
• Integration: Easy integration with local system resources (files, processes)
• Execution: Starts and stops with Sixth (child process lifecycle)
• Dependencies: Any dependencies must be installed on the user’s machine

​

Practical Example

• Run on the user’s machine
• Have direct access to the local filesystem
• Start when needed by Sixth
• Not require network configuration
• Need to be installed alongside Sixth or via a package manager

​

SSE: Hosted Deployment Model

• Installation: Installed once on a server, accessed by many users
• Distribution: Single deployment serves multiple clients
• Updates: Centralized updates affect all users immediately
• Resources: Uses server resources, not local machine resources
• Access Control: Managed through authentication and authorization systems
• Integration: More complex integration with user-specific resources
• Execution: Runs as an independent service (often continuously)
• Dependencies: Managed on the server, not on user machines

​

Practical Example

• Run on a central server
• Connect to databases with server-side credentials
• Be continuously available for multiple users
• Require proper network security configuration
• Be deployed using container or cloud technologies

​

Hybrid Approaches

1. STDIO with Network Access: A local STDIO server that acts as a proxy to remote services
2. SSE with Local Commands: A remote SSE server that can trigger operations on the client machine through callbacks
3. Gateway Pattern: STDIO servers for local operations that connect to SSE servers for specialized functions

​

Choosing Between STDIO and SSE

​

Configuring Transports in Sixth