When I first heard the name MCP, short for Model Context Protocol, I was a bit confused on what it meant. I knew what a machine learning model was, duh, knew what context was, and I knew the definition of a protocol. All that being said, there was something off, something unnaproachable, about the name itself. Combining those three words into a sequence somehow explained what the thing was related to, but without clearly spelling out what it did. Classic programmer naming convention.
This is not the first time software engineers have made bad names for what should be simple concepts. When I was first learning to code, I had no idea what a 'closure' was supposed to be. What does 'rejecting a promise', and how am I supposed to know that a 'callback' is asynchronous? Ehat does Representational State Transfer (REST) mean, and how is it related to an API? Were there really no simpler ways to name these concepts? Scientists can use Haliaeetus leucocephalus in nature journals, but most people will just call them bald eagles.
Despite this epistemological obfuscation, a couple of these terms have entered the mainstream lexicon in the last few years. For example many non-software engineers now know what an API is and can use it in a sentence. For the most part. Most, when talking about an API, will use it in the context of a server, or something related to a database, which is probably accurate but maybe not. An API can refer to any piece of code that exposes a way of working with it.
So, what the hell is an MCP server anyway? At it's core, it's a server that offers a set of tools, dare I say APIs, that the large language model can access programatically, usually interpreting their capabilities and accessing them with the aid of natural language processing. Essentially, it's an API (a server) that an LLM can use to access tools and files.
If that's all it is, and if the mainstream definition of an API is more or less a server, then why don't we just call them MPIs? It's certainly relatable; a human who knows what an API is can almost certainly grasp what an MPI might be. The same way the average person doesn't know that an API can refer to any piece of code that exposes a method (or class) to interface with it, they don't need to understand that an MPI/MCP is more than just an endpoint, but is also a list of instructions on where to find certain files and resources, and contains a standardized data schema (protocol) across instances on how LLMs can access it.
Keeping all this in mind, the very name of THE Model Context Protocol has an inherent assumption that is is THE way for these servers to operate, and that is certainly true as of 2025/2026. Anthropic's standardization serves as the de-facto industry standard, but so was SOAP once upon a time when XML reigned supreme. Very few people write http servers using the core primitives exposed by the programming language; people use Flask or FastAPI in Python, or Express and Koa in Node. Outside of that, in an industry where everyone wants to put their 'stamp' on protocols, it is incredibly likely for the current version of MCP to be known as 'MCP Classic' in a couple of years, once more research is done and a more performant, fully featured version of the protocol gets put together. Perhaps AWS, or Azure, or OpenAI will come out with their own proprietary version of the protocol, offering improved performance or interoperability within their ecoystem. With time, just as SOAP evolved into REST, or into GraphQL, the concept of an MPI and API can stay static even as the framework used to functionally implement them can change from the current MCP paradigm standardized by Anthropic into something else entirely.