Sypha AI Docs
Mcp

MCP Transport Mechanisms

Discover the two core transport methods enabling communication between Sypha and MCP servers: Standard Input/Output (STDIO) and Server-Sent Events (SSE). Both offer unique features, benefits, and ideal applications.

The Model Context Protocol (MCP) offers two fundamental transport methods that facilitate communication between Sypha and MCP servers: Standard Input/Output (STDIO) and Server-Sent Events (SSE). Both transport types provide unique characteristics, strengths, and optimal scenarios for implementation.

STDIO Transport

The STDIO transport operates on your local machine, utilizing standard input/output streams for communication.

How STDIO Transport Works

  1. Sypha (the client) initiates an MCP server as a subprocess
  2. Data exchange occurs via process streams: the client transmits to the server's STDIN, receiving responses from STDOUT
  3. Messages are separated using newline characters as delimiters
  4. All messages follow the JSON-RPC 2.0 format
Client                    Server
  |                         |
  |<---- JSON message ----->| (via STDIN)
  |                         | (processes request)
  |<---- JSON message ------| (via STDOUT)
  |                         |

STDIO Characteristics

  • Locality: Executes on the identical machine as Sypha
  • Performance: Minimal latency and resource overhead (eliminates network layer)
  • Simplicity: Straightforward inter-process communication requiring no network setup
  • Relationship: Exclusive one-to-one connection between client and server
  • Security: Enhanced security through absence of network exposure

When to Use STDIO

The STDIO transport works best for:

  • Local tool integrations operating on the same machine
  • Operations requiring heightened security
  • Applications demanding minimal latency
  • Single-client use cases (dedicated Sypha instance per server)
  • Command-line utilities or IDE plugins

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

The Server-Sent Events (SSE) transport operates on remote servers, facilitating communication through HTTP/HTTPS protocols.

How SSE Transport Works

  1. Sypha (the client) establishes connection to the server's SSE endpoint using an HTTP GET request
  2. A persistent connection forms, enabling the server to stream events to the client
  3. Client-to-server messages are transmitted via HTTP POST requests to a dedicated endpoint
  4. Communication flows through dual channels:
    • Event Stream (GET): Delivers server-to-client notifications
    • Message Endpoint (POST): Handles client-to-server communications
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: Supports hosting on separate machines from your Sypha installation
  • Scalability: Manages concurrent connections from multiple clients
  • Protocol: Functions over conventional HTTP (no specialized protocols required)
  • Persistence: Sustains ongoing connections for server-to-client messaging
  • Authentication: Compatible with standard HTTP authentication approaches

When to Use SSE

SSE transport excels in:

  • Cross-network remote access scenarios
  • Multi-client deployment environments
  • Publicly accessible services
  • Centralized utilities requiring broad user access
  • Web service integrations

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

Your selection between STDIO and SSE transports fundamentally shapes how you deploy and maintain your MCP servers.

STDIO: Local Deployment Model

STDIO servers execute locally alongside Sypha on the same machine, bringing several significant considerations:

  • Installation: Server executables require installation on every user's machine
  • Distribution: Installation packages must be provided for various operating systems
  • Updates: Individual instances need separate update procedures
  • Resources: Consumes CPU, memory, and storage from the local machine
  • Access Control: Depends on local filesystem permission structures
  • Integration: Seamless integration with local system resources (files, processes)
  • Execution: Lifecycle tied to Sypha (operates as child process)
  • Dependencies: All dependencies require local machine installation

Practical Example

A file search tool implemented via STDIO would:

  • Execute on the user's local machine
  • Access the filesystem directly
  • Launch on-demand when invoked by Sypha
  • Operate without network setup requirements
  • Require installation through Sypha or a package manager

SSE: Hosted Deployment Model

SSE servers support remote deployment with network-based access:

  • Installation: Single server installation accessible to multiple users
  • Distribution: One deployment serves numerous clients
  • Updates: Central updates propagate to all users instantly
  • Resources: Leverages server infrastructure rather than local resources
  • Access Control: Governed by authentication and authorization frameworks
  • Integration: Complex integration with user-specific resources
  • Execution: Operates as standalone service (typically continuous)
  • Dependencies: Server-managed, eliminating user-side requirements

Practical Example

A database querying tool leveraging SSE would:

  • Operate from a centralized server
  • Utilize server-side credentials for database connections
  • Maintain constant availability for multiple users
  • Demand appropriate network security measures
  • Deploy via containerization or cloud platforms

Hybrid Approaches

Certain scenarios gain advantages from combining approaches:

  1. STDIO with Network Access: Local STDIO server functioning as proxy to remote services
  2. SSE with Local Commands: Remote SSE server capable of initiating client machine operations via callbacks
  3. Gateway Pattern: STDIO servers handling local operations while connecting to SSE servers for specialized tasks

Choosing Between STDIO and SSE

ConsiderationSTDIOSSE
LocationLocal machine onlyLocal or remote
ClientsSingle clientMultiple clients
PerformanceLower latencyHigher latency (network overhead)
Setup ComplexitySimplerMore complex (requires HTTP server)
SecurityInherently secureRequires explicit security measures
Network AccessNot neededRequired
ScalabilityLimited to local machineCan distribute across network
DeploymentPer-user installationCentralized installation
UpdatesDistributed updatesCentralized updates
Resource UsageUses client resourcesUses server resources
DependenciesClient-side dependenciesServer-side dependencies

Configuring Transports in Sypha

For comprehensive guidance on setting up STDIO and SSE transports in Sypha, complete with examples, refer to Configuring MCP Servers.

On this page