MCP has exactly three roles, and the whole system only makes sense once you stop treating them as interchangeable. The HOST is the LLM application itself — a desktop app, an IDE, a web agent — and it owns two things: the model conversation and the user. Everything the user sees, every turn the model takes, every decision about which tool result to show, flows through the host.
The CLIENT lives inside the host, and it owns exactly one thing: a single connection to a single server, from connect through initialization through use through disconnect. A host that wants to talk to three different servers runs three clients — one per server — not one client juggling three connections.
The SERVER owns a capability surface — tools, resources, prompts — and nothing else. It has no idea what model is running the conversation, no idea what the user asked, no idea what the host's system prompt says. It answers requests over its one connection and stays completely blind to the reasoning happening on the other end. Getting these three responsibilities straight is the entire architecture; everything else in this lesson is detail on top of that.
Analogy🏏Cricket
🏏 Think of it like cricket: Picture Mumbai Indians ahead of an IPL season. The franchise's team management is the HOST — it owns the season's strategy, talks to the fans at the Wankhede, and decides which outside specialists to bring in. It doesn't deal with every specialist directly; it appoints a dedicated liaison for each one. One liaison's entire job is a call with the biomechanics lab in Bengaluru that analyzes Jasprit Bumrah's bowling action; a second liaison's job is a call with the video-analytics vendor in Pune that breaks down Suryakumar Yadav's scoring zones. Each liaison is a CLIENT: it maintains exactly one relationship, with exactly one partner, for the season. When a liaison first connects, it asks the vendor what it can actually offer this year — action-capture reports, injury-risk scores, both — rather than assuming last year's list still holds. The vendors themselves are SERVERS: the biomechanics lab has no idea Mumbai Indians play Chennai Super Kings at the Chepauk on Saturday, no idea who's opening — it just receives a clip and returns a report. It never calls the video-analytics vendor, and that liaison can't reach the biomechanics lab either. If the lab's software glitches or is compromised, the damage stays inside that one report — it can't touch the video feed or the strategy meeting. Separating who owns the strategy, who owns each relationship, and who provides each service is what keeps one bad vendor from becoming a franchise-wide crisis.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.