# How the MCP Everything Server Supports Multiple Transports > Discover how the MCP Everything server supports multiple transports like STDIO HTTP and SSE. It uses a shared factory for isolated server instances, ensuring identical functionality across all connections. - Repository: [Model Context Protocol/servers](https://github.com/modelcontextprotocol/servers) - Tags: internals - Published: 2026-03-01 --- **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`](https://github.com/modelcontextprotocol/servers/blob/main/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. ```typescript 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`](https://github.com/modelcontextprotocol/servers/blob/main/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`](https://github.com/modelcontextprotocol/servers/blob/main/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. ```typescript 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`](https://github.com/modelcontextprotocol/servers/blob/main/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` 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 ```typescript 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`](https://github.com/modelcontextprotocol/servers/blob/main/src/everything/transports/streamableHttp.ts) ### SSE Transport The pure SSE transport ([`src/everything/transports/sse.ts`](https://github.com/modelcontextprotocol/servers/blob/main/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: ```typescript // 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`](https://github.com/modelcontextprotocol/servers/blob/main/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`](https://github.com/modelcontextprotocol/servers/blob/main/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:** ```bash npx ts-node src/everything/transports/stdio.ts # Or after building: node dist/everything/transports/stdio.js ``` **Streamable HTTP transport:** ```bash 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:** ```bash 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`](https://github.com/modelcontextprotocol/servers/blob/main/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`](https://github.com/modelcontextprotocol/servers/blob/main/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`](https://github.com/modelcontextprotocol/servers/blob/main/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`](https://github.com/modelcontextprotocol/servers/blob/main/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.