MCP: The USB Port for AI | Model Context Protocol Explained

Blythe: To really get MCP, you have to realize it’s a three-way conversation, not just two. You’ve got the Host, the Client, and the Server. Most people get confused and think the Client and the Host are the same thing, but they play very different roles in this dance.

Eli: Okay, so walk me through it. If I’m using something like Claude Desktop or a specialized IDE, who’s who?

Blythe: Great question. The Host is the main AI application—it’s the thing you’re actually talking to. It’s the orchestrator. It manages the conversation, holds the memory of what you said two minutes ago, and decides which MCP servers it needs to wake up based on what you’re asking for.

Eli: So the Host is like the brain of the operation, but it doesn't necessarily know how to talk to a specific database or a GitHub repo yet?

Blythe: Precisely. That’s where the MCP Client comes in. Think of the Client as a specialized translator or a protocol adapter that lives inside the Host. For every MCP Server you want to use, the Host creates one specific Client to manage that connection. The Client handles all the boring stuff—the handshakes, the message formatting, and making sure the server is actually awake.

Eli: Ah, so the Host says "I need to see some files," and the Client is the one that actually yells over to the File System Server in a language it understands?

Blythe: Exactly! And then you have the MCP Server itself. This is the "tool provider." It’s a separate program that wraps around a specific data source—like your local files, a Postgres database, or an API like Slack. It doesn't care about the AI model’s internal logic; it just knows how to expose "Resources," "Tools," and "Prompts" in a way the protocol requires.

Eli: I’m catching a theme here. It sounds like this "process separation" is a big deal. Why not just build the GitHub integration directly into the AI app? Why all this extra back-and-forth?

Blythe: Oh, it’s all about security and flexibility. Because the server runs as a separate process, if the server crashes, it doesn't take the whole AI app down with it. Plus, it means you can write a server in Python and connect it to a Host written in TypeScript. The protocol doesn't care about the language, as long as they both speak JSON-RPC 2.0.

Eli: That makes total sense. It’s like how you can plug a mouse into a computer regardless of whether the mouse was made by a different company than the laptop. But how does the server actually tell the client what it can do? It’s not just a "hey, I'm here" kind of thing, right?

Blythe: Not at all. It’s a very formal "Capability Negotiation." When they first connect, they go through this initialization handshake. The client says "Here’s what I can do," and the server responds with "Cool, here are the tools, resources, and prompts I have available for you today."

Eli: It’s like a job interview where the server brings a resume! "I can search flights, I can read your calendar, and I have a template for planning vacations."

Blythe: That is literally what happens! And until that handshake is finished and the client sends an "Initialized" notification, no real work can happen. It ensures that both sides are on the same page before the AI starts trying to execute commands.

Eli: You mentioned three things the server brings to the table—Tools, Resources, and Prompts. I want to dig into those because they sound like the "superpowers" of the MCP world. Let’s start with Tools. If I tell an AI to "delete a file," is that a Tool?

Blythe: Yes! Tools are all about action. They are the "verbs" of the protocol. A tool is an executable function that the AI can decide to call. It’s model-controlled, meaning the AI evaluates the situation and says, "Hey, to finish this task, I need to use the createCalendarEvent tool."

Eli: So, the AI is the one in the driver's seat for tools. But wait, if the AI can just decide to run code, isn't that a bit... risky?

Blythe: It absolutely is, which is why MCP has safety built in. Every tool execution can require user consent. The Host application usually pops up a dialog saying, "The AI wants to send an email. Do you allow this?" You’re always the ultimate authority.

Eli: Good to know I’m not just handing my keys to a robot. Now, what about Resources? How are those different from Tools?

Blythe: If Tools are the verbs, Resources are the nouns. They are passive data sources. Think of them as "read-only" context. This could be the contents of a local file, a database schema, or even a live weather report. The AI doesn't "run" a resource; it "reads" it to get smarter about the conversation.

Eli: Ah, okay. So if I ask the AI to "summarize this document," the document is a Resource. But if I ask it to "upload the summary to my Dropbox," that upload part is a Tool.

Blythe: Spot on. And Resources have these cool things called "Resource Templates." Imagine a URI—sort of like a web address—that has blanks in it. Like calendar://{year}/availability. The AI can fill in the year to get specific data. It’s a very structured way to navigate massive amounts of information without just dumping everything into the prompt at once.

Eli: That is so much more efficient than what we were doing two years ago. Okay, so verbs and nouns—Tools and Resources. What’s the third one? Prompts?

Blythe: Prompts are like recipes or "interaction templates." They’re pre-built instructions that tell the model how to act or how to use a specific set of tools and resources to accomplish a complex goal. For example, a server might provide a "Plan a Vacation" prompt. Instead of you having to explain every step, you just invoke the prompt, and it sets the stage: "You are a travel assistant. Use the flight tool and the weather resource to build an itinerary."

Eli: So it’s a way for developers to bake "best practices" right into the server?

Blythe: Exactly. It keeps the AI from wandering off-track. And unlike Tools, Prompts are user-controlled. You usually trigger them with something like a slash command—think /plan-vacation in a chat box.

Eli: It’s interesting how these three work together. It’s like you’re giving the AI a workspace, a manual, and a toolbox all at once.

Blythe: And the real magic happens when you connect multiple servers at the same time. You could have a Travel Server, a Weather Server, and a Calendar Server all plugged in. The AI can pull the "vacation history" from a resource on one server, check the weather from another, and book the flight using a tool from the third. It turns the AI into a true multi-tasking agent.

Eli: Okay, Blythe, I’m sold on the powers, but I want to talk about the "pipes." How does the data actually move from my computer to the server? I saw something about "stdio" and "HTTP" in the docs.

Blythe: This is where the engineering gets really interesting. MCP supports two main "transports"—which is just a fancy word for the communication channel. You’ve got stdio and Streamable HTTP.

Eli: "stdio" sounds like something from an old computer science textbook. Is that just standard input and output?

Blythe: It is! And it’s incredibly clever for local use. When you use the stdio transport, the MCP client inside the Host application actually launches the MCP Server as a "child process" on your machine. They talk to each other through the same pipes a command-line tool uses to print text to your screen.

Eli: Why would we do that instead of just using a regular network connection?

Blythe: Speed and simplicity! Since it’s all happening on one machine, there’s zero network latency. There’s no need to worry about TLS certificates or port numbers or firewalls. It just inherits your local permissions. If you can access a file, the server can access it because it's running as you.

Eli: That’s perfect for developers working on their own machines. But what if I want my whole team to use the same database server? We can't all run child processes on each other's laptops.

Blythe: That’s exactly why we have the Streamable HTTP transport. This turns the MCP server into a standalone service that lives in the cloud or on a remote server. It uses standard HTTP POST requests for the client to talk to the server, and then it uses something called "Server-Sent Events" or SSE to stream data back to the client.

Eli: So SSE is how the AI can show me it’s working in real-time, like when it’s typing out a long response or searching through a big database?

Blythe: You got it. It allows for that "live" feel. But here’s the catch—you have to be careful not to assume they work exactly the same way. A common mistake is testing everything on stdio and then deploying to HTTP, only to realize your session management or authentication is totally different. Stdio is 1-to-1, but HTTP can be 1-to-many.

Eli: That’s a huge distinction. It’s like the difference between talking to someone in the same room versus calling them on a cell phone. On a cell phone, you have to worry about the signal and who’s paying the bill!

Blythe: Exactly! And regardless of the transport, the actual "language" they’re speaking is JSON-RPC 2.0. Every message is structured with an "ID," a "Method," and "Params." If the client sends a request with ID #5, the server must respond with a result or an error that also has ID #5.

Eli: It’s very orderly. "Here is request five, give me answer five." No getting lost in the shuffle.

Blythe: And then there are "Notifications." These are the only messages that don't expect a response. A server might send a notification saying, "Hey, I just added three new tools to my list," and the client just says "Thanks for the heads up" and updates its registry. It keeps everything synchronized without constant polling.

Eli: I want to trace the life of an MCP session. We talked about the handshake, but what happens after that? Is the connection just "open" forever?

Blythe: It’s a very specific four-phase journey. First is Phase 1: Transport Setup. This is just getting the pipes connected—launching the process for stdio or hitting the URL for HTTP.

Eli: Okay, then comes the handshake we talked about—Phase 2: Initialization.

Blythe: Right. This is where they negotiate versions and capabilities. If the server is using a protocol version from three years ago and the client is brand new, they have to figure out if they can still talk. Once they agree, the client sends that "Initialized" notification, and we move to Phase 3: Discovery.

Eli: Discovery? I thought the handshake already told the client what the server could do?

Blythe: The handshake just says "I support tools." Discovery is when the client actually asks, "Okay, which tools do you have?" The client calls tools/list, resources/list, and prompts/list to get the full catalog. This is super important because it lets the server be dynamic. Maybe today it has a "holiday search" tool because it’s December, but in July that tool disappears.

Eli: That’s smart. So the AI always has an up-to-date menu.

Blythe: Exactly. And then we hit the "steady state"—Phase 4: Operation. This is where the actual work happens. Tool calls, resource reads, and prompt retrievals are flying back and forth. This can last for minutes or even hours during a long coding session or a deep research project.

Eli: And how does it end? Is there a formal "Phase 5: Shutdown"?

Blythe: There is. In stdio, the host usually just closes the pipe, which tells the server it’s time to go to sleep. In HTTP, the client closes the SSE stream. It’s a clean break so that resources like memory and database connections get released properly.

Eli: It’s surprisingly disciplined. I think people often think of AI as this chaotic "black box," but the protocol around it is incredibly rigid and organized.

Blythe: It has to be! If the protocol were chaotic, the AI would never be able to reliably execute a database query without accidentally deleting the whole table. The structure is what provides the safety.

Eli: Speaking of safety, I’m curious about what happens when things go wrong. Because they always go wrong at some point, right?

Blythe: Oh, absolutely. And MCP actually has a really interesting way of handling "oops" moments. There’s a big difference between a "protocol error" and a "tool error."

Eli: Wait, what’s the difference? Isn't an error just an error?

Blythe: Think of it like this: A Protocol Error is like the phone line cutting out. The message was garbled, or you tried to call a number that doesn't exist. A Tool Error, on the other hand, is like the person on the other end picking up the phone but saying, "Sorry, I can't find that file you asked for."

Eli: Ah! So in a tool error, the connection worked perfectly, but the task failed.

Blythe: Exactly. MCP reports those "task failures" as successful protocol responses, but with an isError: true flag in the result. This is vital because it tells the AI, "Hey, I tried, but the file was missing. Do you want to try a different file name?" instead of just crashing the whole session.

Eli: Let’s put all this technical talk into a real-world scenario. I want to plan that Barcelona trip we’ve been joking about. How does MCP actually make that happen in a way that feels seamless?

Blythe: Okay, let’s paint the picture. You open your AI Host—maybe it’s Claude Desktop—and you invoke a Prompt called plan-vacation. You type in: "Barcelona, 7 days, $3000, I love food and architecture."

Eli: Okay, I’ve set the stage. What does the AI do first?

Blythe: The AI doesn't just start guessing. It looks at its available Resources. It hits the Calendar Server to see which week in June you’re actually free. It checks a "Travel Preferences" resource to remember that you hate red-eye flights and prefer boutique hotels.

Eli: So it’s already smarter than a standard travel site because it knows me.

Blythe: Precisely. Now it has context. Next, it switches to Tools. It calls a searchFlights tool on the Travel Server. While it’s doing that, it might also call a checkWeather tool on a Weather Server to make sure you aren't booking during a heatwave.

Eli: And this is all happening in the background?

Blythe: Yep. And as the results come back—through those JSON-RPC messages we talked about—the AI processes them. It finds a flight on the 15th that fits your budget. But wait, it sees you have a dentist appointment that day in your calendar resource.

Eli: Ooh, good catch. So it automatically adjusts?

Blythe: It does! It finds a flight for the 15th instead. It then uses a bookHotel tool—but only after it shows you the options and you click "Approve." Remember, user consent is key. Once you say yes, it calls the createCalendarEvent tool to mark the trip in your schedule and even uses an sendEmail tool to send an out-of-office draft to your boss.

Eli: That is incredible. A task that usually takes me three hours of jumping between tabs was just handled by a few coordinated servers.

Blythe: And the reason it works is that every one of those servers—the Travel one, the Weather one, the Calendar one—all followed the same MCP rules. They all provided clear descriptions of their tools, so the AI knew exactly when to search for weather versus when to search for flights.

Eli: That "description" part seems really important. If the Travel Server just labeled its tool "Search," the AI might try to use it for weather, right?

Blythe: That is actually one of the biggest pitfalls in building these! If your tool description is vague, like "fetches data," the AI gets confused. You have to be specific: "Queries the airline database for round-trip flight options between two airport codes." The better the description, the "smarter" the AI feels.

Eli: It’s like giving someone a clear set of instructions versus just pointing at a pile of tools and saying "fix it."

Blythe: Exactly. And because MCP uses JSON Schema for the inputs, the AI knows exactly what format the airport codes need to be in. It won't try to send "The Big Apple" when the tool is expecting "JFK."

Eli: Okay, for everyone listening who’s ready to jump in and start building or using these—what’s the "action plan"? How do we avoid the mistakes people were making when this first launched?

Blythe: First step: Don't reinvent the wheel. Before you write a single line of code, check the community implementations. There are already MCP servers for GitHub, Slack, Postgres, and local file systems. You can usually just download one and plug it into your Host.

Eli: That’s the "plug-and-play" dream. But if I do need to build a custom one, what’s the first rule?

Blythe: Rule number one: Pick the right transport. If you’re building something for yourself or for local file access, stick with stdio. It’s faster, simpler, and more secure for local data. If you’re building a service for your whole company to use, you’ll need Streamable HTTP, but be prepared for the extra work of setting up TLS and authentication.

Eli: Okay, transport chosen. What about the tools themselves? I’m guessing I shouldn't just put 100 tools on one server?

Blythe: Definitely not. That’s a major pitfall. If you give the AI 100 tools, it has to read 100 descriptions every time it thinks about what to do. It slows everything down and leads to more mistakes. The sweet spot is usually 5 to 15 tools per server. Keep them focused. One server for database queries, another for file operations.

Eli: Like the "Unix philosophy"—do one thing and do it well.

Blythe: Exactly! And when you’re defining those tools, use strict input validation. Since MCP uses JSON Schema, take advantage of it. If a tool needs a number between 1 and 100, define that in the schema. The AI will occasionally hallucinate a weird input, and your schema is the first line of defense to catch it before it hits your backend.

Eli: What about logging? I’ve heard that can be a nightmare with the stdio transport.

Blythe: Oh, this is a classic "day two" problem. Since stdio uses the "standard output" for the protocol messages, if your code accidentally prints "Hello World" or a debug log to the same stream, it’ll break the whole connection. Always, always redirect your logs to stderr (standard error) or a separate log file.

Eli: That is a great pro-tip. I can see someone spending hours scratching their head over why their server crashed just because they added a print statement for debugging.

Blythe: One more thing: Think about the "Sampling" capability. This is a more advanced feature where the server can actually ask the host to run an AI completion. It’s great for "agentic" workflows where a tool might need to ask the AI a follow-up question before it finishes its task.

Eli: So the server can say, "Hey AI, I found three possible files, which one should I summarize?"

Blythe: Exactly! It makes the whole system feel way more interactive. And if you’re ever stuck, use the MCP Inspector. It’s a development tool that lets you test your server in isolation, so you can make sure your JSON-RPC messages are perfect before you even hook it up to a model.