How the MCP Everything Server Supports Multiple Transports

The MCP Everything server supports multiple transports by using a shared createServer() factory that instantiates isolated McpServer instances for each connection, enabling STDIO, Streamable HTTP, and SSE transports to expose identical functionality without modifying core server logic.

The reference implementation in the modelcontextprotocol/servers repository demonstrates architectural patterns for building transport-agnostic MCP servers. By examining how the MCP Everything server supports multiple transports, developers can understand how to decouple protocol handling from business logic, allowing the same tools, resources, and prompts to work across local pipes, HTTP endpoints, and Server-Sent Events streams.

Core Server Factory Pattern

Instead of duplicating server logic, the Everything server centralizes functionality in a factory function located in src/everything/server/index.ts. This pattern ensures transport implementations remain thin wrappers focused solely on communication mechanics.

The createServer Factory

The createServer function constructs a fresh McpServer instance along with supporting infrastructure like task stores and instruction handlers. This factory returns both the configured server and a cleanup function for resource management.

export const createServer: () => ServerFactoryResponse = () => {
  const instructions = readInstructions();
  const taskStore = new InMemoryTaskStore();
  const taskMessageQueue = new InMemoryTaskMessageQueue();

  const server = new McpServer(
    { name: "mcp-servers/everything", title: "Everything Reference Server", version: "2.0.0" },
    {
      capabilities: { /* ... */ },
      instructions,
      taskStore,
      taskMessageQueue,
    }
  );

  // Register tools, resources, prompts, subscription handlers...
  return { server, cleanup: /* ... */ };
};

Source: src/everything/server/index.ts

Each transport calls this factory to obtain an isolated server instance, ensuring complete separation between client sessions.

Transport Implementations

The Everything server provides three distinct transport implementations in separate files under src/everything/transports/. Each follows the same pattern: instantiate transport-specific SDK classes, invoke createServer(), connect via server.connect(transport), and manage lifecycle events.

STDIO Transport

The STDIO transport (src/everything/transports/stdio.ts) enables local process communication through standard input/output streams. It uses the StdioServerTransport class from the MCP SDK and handles graceful shutdown on process interruption.

const transport = new StdioServerTransport();
const { server, cleanup } = createServer();
await server.connect(transport);

process.on("SIGINT", async () => {
  await server.close();
  cleanup();
  process.exit(0);
});

This transport requires no network configuration and runs as a standard Node.js CLI, making it ideal for local development and shell integration.

Streamable HTTP Transport

The Streamable HTTP transport (src/everything/transports/streamableHttp.ts) exposes the server via Express over HTTP with resumable Server-Sent Events support. It maintains an in-memory EventStore and manages multiple concurrent sessions using a Map<string, StreamableHTTPServerTransport> keyed by MCP sessionId.

The implementation handles three HTTP methods at the /mcp endpoint:

• POST – Creates new sessions or reuses existing ones based on the mcp-session-id header
• GET – Streams responses via SSE, supporting resumption from Last-Event-ID
• DELETE – Terminates active sessions and cleans up resources

if (!sessionId) {
  // New client connection
  const { server, cleanup } = createServer();
  const eventStore = new InMemoryEventStore();
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: () => randomUUID(),
    eventStore,
    onsessioninitialized: (sid) => transports.set(sid, transport),
  });
  await server.connect(transport);
  await transport.handleRequest(req, res);
} else {
  // Existing session
  const transport = transports.get(sessionId)!;
  await transport.handleRequest(req, res);
}

Source: src/everything/transports/streamableHttp.ts

SSE Transport

The pure SSE transport (src/everything/transports/sse.ts) provides a dedicated Server-Sent Events endpoint at /sse with a separate /message endpoint for client-to-server communication. Unlike the streamable HTTP transport, this implementation uses distinct URLs for streaming and messaging.

Each new SSE connection creates an SSEServerTransport instance stored in a session Map:

// New SSE connection at /sse
const transport = new SSEServerTransport("/message", res);
transports.set(transport.sessionId, transport);
await server.connect(transport);

// POST messages to /message
const transport = transports.get(sessionId)!;
await transport.handlePostMessage(req, res);

Source: src/everything/transports/sse.ts

Session Management and Cleanup

All transports implement consistent lifecycle management through the cleanup function returned by createServer(). When a connection closes, each transport registers an onclose handler that removes the session from the transport Map and invokes cleanup(). This ensures resources like task timers and simulated logging (handled in src/everything/resources/subscriptions.ts) are released regardless of transport type.

This unified cleanup approach prevents memory leaks across long-running HTTP connections and enables the server to handle STDIO, HTTP, and SSE clients concurrently without resource contention.

Running the Different Transports

Start each transport implementation independently based on your deployment requirements.

STDIO transport:

npx ts-node src/everything/transports/stdio.ts

# Or after building:

node dist/everything/transports/stdio.js

Streamable HTTP transport:

export PORT=3002  # Optional, defaults to 3001

node dist/everything/transports/streamableHttp.js

# Clients POST to http://localhost:3002/mcp

# SSE streaming available via GET to same endpoint

SSE transport:

node dist/everything/transports/sse.js

# Connect via GET http://localhost:3001/sse

# Send messages via POST http://localhost:3001/message?sessionId=...

Summary

• Factory Pattern: The createServer() function in src/everything/server/index.ts centralizes server logic, enabling transport-agnostic tool and resource registration.
• Transport Isolation: Each connection receives a fresh McpServer instance, preventing session leakage between STDIO, HTTP, and SSE clients.
• Consistent Cleanup: All transports invoke the shared cleanup function on close, ensuring proper resource disposal via server.close() and transport-specific teardown.
• SDK Integration: Transport implementations leverage official MCP SDK classes (StdioServerTransport, StreamableHTTPServerTransport, SSEServerTransport) for protocol compliance.
• Session State: HTTP-based transports maintain session maps using sessionId keys, with the Streamable HTTP transport supporting resumable events through InMemoryEventStore.

Frequently Asked Questions

What transports does the MCP Everything server support?

The server supports three primary transports: STDIO for local process communication, Streamable HTTP for resumable HTTP+SSE connections, and pure SSE for dedicated Server-Sent Events streaming. Each transport resides in its own file under src/everything/transports/ and uses the same core server factory.

How does the server handle session cleanup across different transports?

Every transport implementation registers an onclose handler that calls the cleanup() function returned by createServer() and removes the session from the active transports Map. This ensures that resources like task timers and subscription handlers defined in src/everything/resources/subscriptions.ts are released consistently, whether the client disconnects from an HTTP stream or closes a STDIO pipe.

Can I add a custom transport to the Everything server?

Yes. Implement any transport class that conforms to the MCP SDK's transport interface, instantiate it in a new file under src/everything/transports/, call const { server, cleanup } = createServer(), execute await server.connect(transport), and manage session lifecycle. The core server logic requires no changes to support new transport layers.

What is the difference between Streamable HTTP and SSE transports in MCP?

The Streamable HTTP transport (src/everything/transports/streamableHttp.ts) uses a single endpoint (/mcp) that handles POST requests, GET streaming, and DELETE operations with resumable event support via Last-Event-ID. The SSE transport (src/everything/transports/sse.ts) separates concerns into two endpoints: /sse for the event stream and /message for client-to-server posts, without built-in resumption capabilities.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}