2
The Hierarchy of Control and Responsibility 0:59 Lena: So, we mentioned that host, client, and server structure, but I really want to get into the weeds of who actually does what. In my head, I used to think of the AI as the boss—you know—the one giving the orders. But in MCP, it sounds like the hierarchy is a bit more nuanced than that.
1:17 Miles: You’ve hit on something vital right out of the gate. The host is the real center of gravity. Think of the host—like Claude Desktop, Cursor, or your own custom app—as the actual environment where the AI lives. It’s the orchestrator. It manages the user session, holds the conversation history, and most importantly, it decides which MCP servers it’s even going to talk to in the first place.
1:41 Lena: Right, so the host is like the building that houses the office. And then the MCP Client is... what? Like the receptionist?
1:49 Miles: Actually, that’s a great way to put it. The client lives inside the host, and its job is to maintain that stateful, one to one connection with a server. If the host wants to talk to a Postgres database and a Slack channel at the same time, it’ll spin up two separate clients. Those clients handle the boring stuff—the JSON-RPC 2.0 handshake, the capability negotiation, and making sure the connection doesn't just drop into a black hole.
2:15 Lena: I noticed in the technical guides that there’s a big emphasis on "stateful" sessions. Why does that matter so much? Most APIs I work with are stateless—you send a request, you get a response, and the server forgets you ever existed.
2:29 Miles: That’s the big shift. Because MCP uses persistent connections—often over stdio for local stuff or SSE for remote—it allows for a continuous back and forth. The AI isn't just shouting into the void—it’s having a dialogue with your data. But this is also where people trip up. A common failure pattern is treating the host like a thin UI shell and pushing all the operational logic somewhere else. If you don’t define who owns the retry logic or the authentication scope, the whole thing becomes brittle.
3:01 Lena: That makes sense. So if the host and client are the infrastructure, the server is where the actual "tools" live. I saw that these servers are usually lightweight programs. They don’t have to be these massive, bloated services, right?
0:46 Miles: Exactly. They’re often just small scripts—TypeScript or Python—that wrap an existing API. But here’s the kicker: the server is responsible for exposing three specific primitives—Resources, Tools, and Prompts. And it has to do so with a stable contract. If you change a tool schema on the server side without versioning it, you’re basically giving the AI a broken map. It’ll try to call a function that doesn't exist anymore, and the whole user experience falls apart.
3:42 Lena: It’s interesting you mention ownership. One of the reports I was reading emphasized that "syntax migration" is the easy part—it’s the "ownership migration" that’s hard. It’s not just about moving your function calling code into an MCP server—it’s about deciding who owns the rollback playbooks when a connector starts acting up.
4:01 Miles: Precisely. In the old days—well, 2024—if your custom tool call failed, you just debugged your app code. Now, that tool call might be coming from a third party MCP server you found on GitHub. You have to think about governance. Where do you put the policy controls? If you put them in the prompt, the AI might hallucinate its way around them. MCP suggests putting those controls in the architecture—at the host level—so you can evaluate a tool call before it ever leaves the building.
4:31 Lena: So it’s about drawing hard boundaries. The host handles the user and the safety, the client handles the plumbing, and the server handles the data. It sounds like a much cleaner way to build, but it definitely requires more upfront design than just slapping an API key into a script.
4:48 Miles: It absolutely does. You’re trading a bit of quick and dirty speed for long term scalability. But when you’re dealing with enterprise grade AI, that’s a trade you have to make. You can’t have silent schema drift or "ghost" failures happening in a production environment where an AI is supposed to be managing your Jira tickets or querying your financial data.