The Hungry Human's Guide to MCP
Using an analogy of a Food Truck Festival to explain how the Model Context Protocol works & why it matters.
One of my favorite pieces of technical writing is The Beer Drinker’s Guide to SAML, which explains an unpopular and confusing protocol in the most human way possible.
After a few weeks of writing about MCP, but still struggling to explain it to new people, I decided to try out an analogy of my own. This post will break down what MCP is and how it works, all through the analogy of a food truck festival.
What is MCP and why does it exist?
The Model Context Protocol (MCP) provides a standardized way for AI applications (like Claude Desktop or Cursor) to connect to third-party tools and data sources (like Slack, Gmail, or your local files).
Instead of needing to build custom API integrations for each app, MCP creates a shared language for plugging in new tools. Each app or data source then becomes a kind of "toolbox" (called an MCP server) that you can plug into your AI application. Your AI application can browse those toolboxes and then invoke the specific tools it needs to get the job done.
How Does It All Work?
Let’s go back to the image of a food truck festival, and imagine that you’re there as an end-user.
You're hungry. Maybe you want tacos. Maybe you want a smoothie. Maybe both. You just want food — fast — without wandering around or comparing menus.
Fortunately, you brought along a friend:
🤖 Your Helpful Friend and Her iPad = MCP Host & Client
You brought along a friend, who’s prepared and ready to help. You say:
“I’m craving tacos. And maybe a drink!”
Your friend is not doing everything by memory. She has an iPad that’s equipped with the festival’s app, where she can:
Search for food trucks
Browse their menus
Submit orders (“engage with menu items”) in a consistent format across trucks
Your friend might ask clarifying questions about what you want to order, and then place an order on the iPad, using the best possible menu items to fulfill your wishes.
The friend is your AI tool — she listens to your request and figures out what needs to happen. Then, she uses the iPad to connect with the right tools to accomplish that goal — in this case, by ordering tacos.
In MCP terms, your friend is also known as the MCP host and her iPad app is the MCP client, which allow you to:
Discover servers (the food trucks)
Understand what tools (menu items) they offer
Format and send valid requests
🚚 The Food Trucks = MCP Servers
Each food truck is a MCP server, with its own specialty:
One serves tacos
Another makes smoothies
Another sells fresh fruit bowls
Each truck has a menu of options — in MCP terms, these are the tools that the MCP server offers. For example, while a Mexican-themed food truck might sell tacos and sodas, the the Filesystem MCP Server might offer tools to read and write files.
🎪 The Festival Rules = The Protocol
The most important part here is that, at the food truck festival, every truck uses the same format for its menu and how it handles orders or requests.
This means there’s a consistent way to access their menu items (MCP tools). Regardless of who owns the food truck or what type of cuisine they offer:
Menus must be printed in a standard layout
Orders must be supported via the app
Ingredients must be labeled consistently
This shared system is the MCP protocol itself.
The protocol provides consistent standards that ensure the food trucks (MCP servers) and your iPad-bearing friend (MCP host/client) can speak the same language.
Why This Beats Doing It All Yourself
Without your friend and the shared protocol, you’d have to:
Visit every truck
Learn their individual process
Repeat your preferences and payment info every time
With MCP, it’s much more streamlined; you have a common format that your friend can easily work with to order you something delicious.
P.S. — if you want to see an MCP architecture diagram with no food trucks involved, here’s the official one from the docs:
Remember:
MCP Host = Your Friend
MCP Client = The iPad
MCP Protocol = The Festival Rules
MCP Server = Food Truck
MCP Server Tools = Menu Items (not shown here, but accessed via web APIs or working with local data sources)
APIs vs. MCP: Sit-Down Restaurant vs. Food Trucks
People often also wonder how MCP servers are different from APIs.
You can think of traditional APIs like calling individual restaurants with narrow menus to place an order:
Each restaurant has its own phone number and navigation scheme.
You need to be ready with your order well ahead of when you’re asked for it.
You have to say everything just right to avoid mistakes.
Your friend (the AI tool) can still help you order food from a restaurant, but she needs to get the exact details correct. It’s not as easy as the iPad method.
Using MCP servers is more standardized and dynamic, like a food truck festival:
There’s a shared menu format.
Your friend can browse and combine tools/orders from different trucks dynamically.
New food trucks can be automatically supported if they use the standard.
So in summary — APIs work well for individual restaurants with specific needs. MCP is built for the full festival, where standardization helps provide consumers with variety and ease-of-use.
Where the Analogy Breaks
This analogy is far from perfect. A few example flaws:
Your friend (the AI tool) isn’t a genius. She needs your help, and sometimes still places the wrong order.
The food trucks aren’t there and waiting quite yet. You still have to bring your own trucks (i.e., install servers) before your friend can order from them.
The festival app is not particularly user friendly at the moment (and requires copy/pasting JSON into random config files).
Despite the limitations, let me know if this analogy was helpful!
I also recommend this analogy about trip planning from Vineet Agarwal, and this one about keys from Norah Sakal. Let me know if you come across different / better comparisons - I’m all ears.