MCP Servers
MCP Transport Mechanisms

MCP Communication Protocols

Understand the two core transport methods for Bwat-MCP server communication: Standard Input/Output (STDIO) and Server-Sent Events (SSE), each with unique benefits and ideal use cases.

The Model Context Protocol (MCP) supports two primary communication channels between Bwat and MCP servers, offering flexibility for different deployment scenarios.

STDIO Transport

STDIO enables direct local communication through system input/output streams.

How It Operates

Bwat launches the MCP server as a child process. Communication flows through process streams:

  • Requests via STDIN
  • Responses via STDOUT
  • Newline-delimited JSON-RPC 2.0 messaging
Bwat                    MCP Server
  |                         |
  |<---- JSON payload ----->| (STDIN)  
  |                         | (processes)  
  |<---- JSON response -----| (STDOUT)  
  |                         |

Key Attributes

  • Local Execution: Runs on the same machine as Bwat
  • High Performance: Minimal latency with no network overhead
  • Simple Setup: No network configuration required
  • Secure: No external exposure
  • 1:1 Relationship: Single Bwat instance per server

Ideal Use Cases

  • Local machine tools and integrations
  • Security-sensitive operations
  • Low-latency requirements
  • Single-user scenarios
  • CLI tools and IDE extensions

Implementation Sample

import { Server } from "@modelcontextprotocol/sdk/server/index.js"
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"
 
const mcpServer = new Server({ name: "local-service", version: "1.0.0" })
// Register functionality...
 
const transport = new StdioServerTransport(mcpServer)
transport.listen()

SSE Transport

SSE facilitates remote communication via HTTP/HTTPS connections.

How It Functions

  • Bwat initiates persistent SSE connection via HTTP GET
  • Server pushes events through this channel
  • Bwat sends requests via separate HTTP POST endpoint
  • Dual communication channels:
    • Event Stream (GET): Server → Bwat
    • Message Endpoint (POST): Bwat → Server
Bwat                          Server
  |                              |
  |---- GET /events ------------>| (SSE connection)  
  |<---- Event stream -----------| (persistent)  
  |                              |  
  |---- POST /message ---------->| (request)  
  |<---- SSE response -----------| (reply)  
  |                              |

Key Attributes

  • Remote Capable: Cross-machine communication
  • Scalable: Supports multiple concurrent clients
  • Standard Protocol: Uses conventional HTTP
  • Persistent: Maintains open connection for push notifications
  • Authenticable: Supports standard HTTP auth

Ideal Use Cases

  • Network-accessible services
  • Multi-user environments
  • Publicly available tools
  • Centralized services
  • Web service integrations

Implementation Sample

import { Server } from "@modelcontextprotocol/sdk/server/index.js"
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js"
import express from "express"
 
const app = express()
const mcpServer = new Server({ name: "remote-service", version: "1.0.0" })
// Register functionality...
 
const transport = new SSEServerTransport(mcpServer)
app.use("/mcp", transport.requestHandler())
app.listen(3000, () => console.log("MCP service running on port 3000"))

Deployment Considerations

STDIO: Local Implementation

  • Installation: Required on each user machine
  • Distribution: OS-specific packages needed
  • Updates: Manual updates per instance
  • Resources: Consumes local system resources
  • Access: Uses local filesystem permissions

Example Use Case: A local file search tool would:

  • Execute on the user's machine
  • Access local files directly
  • Launch with Bwat as needed
  • Require no network configuration

SSE: Hosted Implementation

  • Installation: Single server deployment
  • Distribution: Centralized access
  • Updates: Instant global updates
  • Resources: Uses server resources
  • Access: Managed via authentication

Example Use Case: A cloud database tool would:

  • Run on central servers
  • Maintain persistent connections
  • Serve multiple users simultaneously
  • Require proper network security

Protocol Comparison

FactorSTDIOSSE
LocationLocal onlyLocal or remote
ConnectionsSingleMultiple
SpeedFasterNetwork-dependent
SetupSimpleMore complex
SecurityInherentRequires configuration
NetworkNot requiredMandatory
ScalabilityLimitedHighly scalable
DeploymentPer-machineCentralized
MaintenanceDistributedUnified

Hybrid Approaches

  • STDIO Gateway: Local servers that proxy to remote services
  • SSE Callbacks: Remote servers triggering local operations
  • Combined Architecture: Local STDIO for core functions with SSE for extended capabilities

For configuration details and practical examples, see MCP Server Configuration Guide.