Transports: How a Client and Server Actually Communicate

Recall Module 7’s own closing promise — every capability this course has built so far assumed a Client and Server were already, somehow, talking to each other. This module covers the real, literal channel that makes that possible, and an honest, current warning about a transport many tutorials still show that’s genuinely no longer the recommended choice.

stdio — local process communication

Recall Module 3’s own local filesystem example — this is the real, actual transport behind it.

flowchart LR
    H[Host process] -->|writes to stdin| S[Server process]
    S -->|writes to stdout| H

stdio genuinely means the Client and Server communicate through real, standard input and output streams, as two processes running on the same, real machine. Let’s see this concretely.

We’ll launch a real, local MCP server as a subprocess, communicating purely through stdio.

from fastmcp import Client

async def main():
    async with Client("my_server.py") as client:  # launches the real server as a local subprocess
        tools = await client.list_tools()  # communication happens over real stdin/stdout
        print(tools)

Notice there’s genuinely no network involved at all — the Host literally starts the Server as a real, child process, and the two talk through real, ordinary pipes. This is precisely why stdio is the real, standard choice for something like Claude Desktop reading your own, local files: no network, no real latency, no real authentication needed, since both processes are already running under your own, trusted user account.

Streamable HTTP — the real, current remote transport

Recall Module 3’s own remote GitHub example — this is the real, actual transport behind it.

flowchart LR
    H[Host] -->|HTTP request| S[Remote Server]
    S -->|HTTP response, streamed| H

Streamable HTTP genuinely means the Client and Server communicate over a real network connection, using real HTTP requests, with the Server able to stream a real, incremental response back — recall your own streaming coursework’s own real value here, letting a Client see a real answer forming, rather than waiting for the entire response at once.

A real, honest, important deprecation

This is worth stating directly, since it’s genuinely the kind of detail that separates current, accurate knowledge from an outdated tutorial. Recall Module 1’s own real, dated version history — MCP’s original remote transport was HTTP+SSE (Server-Sent Events), and it was genuinely, officially deprecated in the real 2025-03-26 spec revision, replaced by Streamable HTTP. If you encounter a tutorial or an older, real codebase using HTTP+SSE directly, treat it as outdated — Streamable HTTP is the real, current, recommended choice for any new, remote MCP server.

Real-world constraints worth taking seriously

It’s worth being honest about what changes the moment a transport crosses a real network boundary, rather than staying local.

Network reliability: recall stdio’s own real guarantee — two local processes on the same machine essentially never lose their connection. A real, remote HTTP connection genuinely can, and your Client needs real, deliberate retry logic, echoing your own agent coursework’s resilience discipline.

Authentication: stdio genuinely needs none — both processes already run under your own trusted account. A real, remote Server has no such guarantee, and needs genuine, real authentication, covered fully once this course reaches security.

Latency: a real, local stdio call is essentially instantaneous. A real, remote HTTP call carries genuine, real network latency — worth accounting for directly in any user-facing application, echoing your own latency coursework’s own real concerns.

Choosing between them, honestly

flowchart TD
    A{Where does the\nserver actually run?} -->|Same machine| B[stdio]
    A -->|Remote / different machine| C[Streamable HTTP]
    B --> D["No auth needed,\nno network reliability concerns"]
    C --> E["Needs real auth,\nreal retry logic, real latency handling"]

Common mistakes worth avoiding

Using HTTP+SSE in a new, real server. Recall this module’s own direct warning — it’s genuinely deprecated as of the 2025-03-26 spec revision; use Streamable HTTP for any new, remote deployment.

Assuming stdio’s simplicity — no auth, no retries — applies to a remote deployment too. Recall this module’s own honest, real constraints — the moment a Server runs on a genuinely different machine, authentication and network reliability become real, unavoidable concerns.

Choosing stdio for a Server meant to be shared across many, real, different users. Recall stdio’s own real, local-process nature — it’s genuinely appropriate for one user’s own, local tools; a Server meant to serve multiple, real, separate users needs a genuine, remote transport instead.

What you should take away from this module

• stdio genuinely means two local processes communicating through real, standard input and output — no network, no auth needed.
• Streamable HTTP is the real, current, recommended transport for remote servers, replacing the now-deprecated HTTP+SSE as of the 2025-03-26 spec revision.
• Crossing a real network boundary introduces genuine, real constraints — reliability, authentication, latency — that a local, stdio connection never has to face.

Where this goes next

The next module puts everything from Modules 5 through 8 together, building a complete, real MCP server from scratch, version by version — a tool, a resource, a prompt, and genuine error handling, all in one working file.