This protocol underwent development at a speed we couldn't possibly comprehend. In a world where each frontier lab is fighting for supremacy in their proprietary models and software, and each country trying to do the same, we had a moment of unison — a ceasefire in the war for the betterment of the world, if I may. It takes quite a big thing to bring that about.
0 comments
Sign in to comment.
I guess it would be extremely wrong to start blogging again but not have this as my first topic.
Here we go — Model Context Protocol, MCP. Sounds so weird, but I owe a lot to this one protocol (the real ones know).
As I write this, I don't know what direction this blog post will go in — do I intend to explain MCP? Do I plan on sharing my experiences with MCP? I don't know yet — we'll find out. However, I would like to clarify one thing - this blog is entire hand-written. I only use AI for fact checking, grammar correction and image generation - so pardon the em-dashes.
As I sit to try and explain what exactly the Model Context Protocol is, I realise that it's a concept that took me so long to wrap my head around — but once I did, boy did it blow my mind. A single concept, a single protocol that holds so much potential; something that (in my extremely experienced opinion, of course) is one of the biggest things in terms of protocols after HTTP. But regardless, bear with me — this takes time to wrap one's head around.
Let's start off with a simple, age-old problem: logistics and shipping. Basically, the transportation of goods from one place to another. Talking particularly about the sea, you have boats made in numerous shapes and sizes. Similarly, the goods that need to be transported also come in various shapes and sizes. If the workers at the port were to load each good separately onto whatever boat they need to load, they would have to individually figure out the loading and fitting of each item, with its own details (fragility, refrigeration — so many variables), and then also have to figure it out differently for each boat based on the shape of it.
Simple words — if there are M different shapes and sizes of boats, and N different goods to be transported, the workers need to come up with M × N loading strategies. And God forbid one of the boats has even the smallest redesign — it becomes the port workers' responsibility to alter their loading plans for each damn good they wanna transport. And if that wasn't enough responsibility on them, if the tiniest of requirements of any one good changes, it's again the responsibility of those unfortunate port workers to make sure there is a way for each boat to handle the new requirements of this good. I don't think they're paid enough for that, man — and this is what we computer geeks call "The M × N Problem".
So how do we solve this? Shipping containers. Yes, those very things that were a peak battleground in PUBG, that place where Hamza and Major had their final battle in Dhurandhar: The Revenge. It's quite simple, actually. The port workers are clear — this is a shipping container: standard shape, standard size. It has facilities to handle every damn requirement a goods manufacturer might have, and is made to fit onto boats. Now each goods manufacturer is supposed to load their items onto the shipping container, and each boat maker needs to make sure the boats are designed such that they can carry these containers (and multiple of them, if you want profit). If either of the sides fails to do so — oops, I guess? Either the goods don't get loaded, or the boat is never in use. The port workers can finally do what they are paid to do — take each container, and load it onto the boat safely.
And if either a goods manufacturer requires a new facility that doesn't already exist in these containers, or the ship manufacturers have a collective change in infrastructure — only then do the port workers need to put in additional effort. That is, quite simply, changing the container as per requirements. In the worst case, if all M boat makers and all N goods manufacturers all want changes at the same time, the amount of work the workers need to do still goes down drastically — all the way from M × N to now just M + N changes (one for each boat maker's required change, one for each goods manufacturer's change).
Long-ass explanation, huh? Sorry. Let me tell you why I did this lmao — it's actually an analogy. I think we can all agree that our favourite LLMs (be it ChatGPT, Claude, Gemini) reached a whole different level when they grew from being simple chatbots to tools that had live access to third-party software. Suddenly, when you asked GPT "what's the best way to deal with this issue in my project, and divide it amongst my team?", you went from getting a simple answer of "oh it could be an xyz fix, create Jira tickets and assign" to the agent actually searching the internet for people facing similar issues, reading your codebase on GitHub to find the actual problem, and then automatically creating the issues on Jira and assigning them to your teammates as well. Frickin' ingenious stuff!
Now each AI agent, or LLM (ChatGPT, Claude, Gemini, Perplexity etc.), in this situation is a boat manufacturer. Each third-party tool (GitHub, Jira, Web Search etc.) becomes a good that needs to be transported.
For a single change in any third-party software, the connection between an AI agent and the third-party tool (analogous to the port workers) needs to change for each AI agent to correctly connect to the new version of that software. Similarly, for any update in the AI agent, the connection needs to change for each software to be correctly called by the AI agent. The M × N problem again.
And that's where the Model Context Protocol steps in — our beloved shipping container.
Quite simply, every AI agent that wants to interact with third-party tools must support the universal standards of MCP and develop themselves to carry the standard (universal, third-party agnostic) MCP containers in accordance. Every third-party software that wants to be ~~exploited~~ called by an AI agent needs to expose their APIs, or different aspects of their software, as MCP tools, which directly fit into the containers. Any change on either end gets handled by the respective side itself, without anything else being disturbed. Solid.
This seems like one problem solved — what's so huge about this? But this one tiny protocol unlocks a world of possibilities. It's incredible. Before I go ahead and tell you why, lemme quickly explain some tech behind it so we're on the same page going forward. For a detailed understanding of how to implement it and stuff, of course, go to modelcontextprotocol.io, but for a quick brief:
Now each MCP server can offer as many tools as they want. For example, if GitHub offers an MCP server, it can provide tools to pull, push, fetch, view PRs, create issues — the possibilities are limitless. Any MCP client that connects to the server automatically gets access to these tools after the JSON-RPC 2.0 handshake. Simply put, while establishing the connection between server and client, there is a discovery phase wherein the client requests the server's offerings by calling certain MCP-standard endpoints like tools/list, resources/list and prompts/list (more AI terms beyond tools), and the server responds with everything it has available, a description of each, the required input format it expects the client to send, and the format of output it will send back to the client.
This, in my eyes, opens up a very crucial use case of modern-day artificial intelligence. First, it had the ability to understand a problem and give us step-by-step solutions to it. Then, it got individual autonomy — it could execute singular API calls or functions in those steps. However, if there were multi-step problems — things that required executing one step, judging the response of it, thinking, and then deciding what's the next best step to do (or, as we call it, being a damn human and using our brains) — that sounded like a far-fetched dream. But as we all see, these AI labs ain't stopping their development. With MCP, this became the easiest thing ever.
Lemme give you a quick example. Imagine you're building a restaurant management system. Behind the scenes, it has a database with tables like:
Now suppose the restaurant manager asks a seemingly simple question:
"For this customer, how much have they spent in total, and on average, how many failed payment attempts do they make before successfully paying each bill?"
As humans, we instinctively know how to solve this. We'd find all the bills associated with that user, add up their amounts to calculate the total spend, look up all the transactions linked to those bills, count the successful and failed payment attempts for each bill, compute the failure-to-success ratio, and finally average that ratio across all the customer's bills.
The problem is that traditional software can't "figure this out." Unless someone has already written backend code that performs exactly these steps and exposed it as an API, the restaurant manager has no way of asking this question. If tomorrow they want to know the average bill value on rainy days, or which payment method fails most often after 9 PM, that's another feature request, another backend endpoint, and another deployment.
Now imagine instead that your backend exposes a handful of generic tools through an MCP server — for example, tools to retrieve users, bills, and transactions. The AI agent doesn't need a custom API for every possible question. It understands what information each tool provides, decides which tools to call, chains the results together, performs the required calculations, and arrives at the answer on its own.
In other words, instead of developers anticipating every question users might ask, they simply expose the building blocks. The AI figures out how to combine those building blocks to answer the question.
And that's where things get interesting. Once the AI has the raw data, it isn't limited to answering only the question you asked. It could generate a histogram of payment failures, identify the hours during which transactions are most likely to fail, compare customer spending patterns across weekdays and weekends, detect unusual payment behaviour, or answer follow-up questions — all without anyone writing a single new API for those specific analyses.
This is a simple example. Extrapolate this to a larger, more complicated scale. This is the beauty of the Model Context Protocol.
And not just this — the best part about this thing is the universal agreement to adopt it. Introduced by Anthropic, this didn't end up becoming "another one of Dario's escapades"; it soon got adopted by OpenAI, Microsoft, Meta, Google — the whole shebang. The frontier labs and tech giants pledged to contribute more towards the MCP front, and it was eventually donated to the Agentic AI Foundation under the Linux Foundation. That's huge. This protocol underwent development at a speed we couldn't possibly comprehend. In a world where each frontier lab is fighting for supremacy in their proprietary models and software, and each country trying to do the same, we had a moment of unison — a ceasefire in the war for the betterment of the world, if I may. It takes quite a big thing to bring that about.
Anyways, enough romance about a protocol — time to touch some grass. More about my experiences with MCP, or why I owe a lot to this protocol, in some other post, maybe? Cheers.