Practical MCP with FastMCP & LangChain

The Big Picture

When a client (like Claude or an IDE) calls a tool on your MCP server, the request doesn't jump straight into your code. It passes through five layers, each with a distinct job, before it reaches the function you wrote. The response then travels back down through the same layers. Understanding this stack helps you know where to hook in when you need logging, authentication, or any custom behavior.

The lowest layer is Transport. This is the raw wire — how bytes physically move between the client and your server. It could be standard input/output for local processes, Server-Sent Events for legacy HTTP setups, or Streamable HTTP for modern deployments. The transport doesn't understand what's inside the messages. It just moves them reliably from one side to the other.

One level up sits the Session. The ServerSession object takes those raw bytes and turns them into structured JSON-RPC messages. Each connected client gets its own session, which tracks the conversation: parsing incoming requests, serializing outgoing responses, and keeping track of which client is which. This is also where the session_id lives, which isolates one client's data from another's. You rarely interact with the session directly, but it's always there behind the scenes, managing the connection.

Above the session is the Middleware Chain. Before a request ever reaches your code, it passes through every middleware you've registered, in order. Each middleware can inspect the request, modify it, log it, time it, reject it, or just pass it along by calling call_next(). After your code returns a result, the response flows back down through the same middleware chain in reverse, so each middleware also gets a chance to modify or log the response. If you've ever used middleware in web frameworks like Express or Django, this works the same way.

Next comes the Context. FastMCP creates a fresh Context object for every request and hands it to your code as ctx