What is MCP? A Long-Form Explanation

Preamble

In the past two years, the three letters MCP have been repeatedly mentioned in the AI circle, becoming a common topic. But what it actually is, most people can’t say clearly.

Let’s rewind the clock two years. Back then, large language models, to put it bluntly, were like a learned blind man. They had read mountains of books and could quote scriptures at the drop of a hat, but their knowledge stopped at the moment training was completed. Ask them about today’s news or the current stock price, and they had no idea. Ask them to do something for you – book a ticket, look up some data, edit a document – they were useless, only able to chat with you in a dialog box. Extremely clever, but completely unable to interact with anything.

Look at today. The same type of models can already access real-time information online, read files you just shared with them, invoke a series of tools to run errands for you, and step-by-step complete a real task. In just two years, it has transformed from a brain trapped in a dialog box into an assistant that can reach out into the real world to get things done.

What happened in between that made a blind man open his eyes and grow hands? There is more than one reason, but the most critical piece of the puzzle is called MCP, which stands for Model Context Protocol. Note: it’s MCP, not MPC – that’s something else entirely.

This article is about exactly this: how models went from “just talking” to “being able to act”, what role MCP played in this transformation, and why this seemingly unremarkable protocol, which only appeared at the end of 2024, spread across the entire industry in just over a year, even being voluntarily adopted by the biggest competitor. In the end, it solves an old problem that appears repeatedly in computer history, is always difficult, and once solved, triggers a wave of growth. Let’s take it slowly.

1. Where MCP Came From: Twelve Months of a Protocol

This chapter only tells the story – the background against which MCP emerged, and how it went from an internal company specification to the foundation of an entire industry in one year. How it works specifically is left for Chapter 2.

1.1 AI’s Shift: From “Chatting” to “Wanting to Get Things Done”

When ChatGPT became popular at the end of 2022, expectations for AI were simple: you ask, it answers. It was a super search engine plus a super essay teacher. It stayed in the dialog box, outputting text, and you used that text yourself.

By 2023 and 2024, the wind had changed. People were no longer satisfied with AI “talking”; they wanted it “doing”. Help me book a flight, check this month’s sales data, submit this code, organize my inbox. This kind of assistant that “does things for you” is called an agent in the industry.

Once it shifted from “talking” to “doing”, an old problem became immediately unbearable. No matter how smart the model, by default it cannot reach your current calendar, your company’s database, or the document you are writing. Even if it can search public information online, it still cannot access your private systems. For it to do things for you, it first needs to be able to reach these things. If it can’t, all its intelligence is just spinning its wheels.

To put it metaphorically, it’s like hiring an incredibly smart secretary locked inside a soundproof glass room. He can read newspapers and watch TV through the glass, knows everything about the outside world, but cannot touch any of the documents on your desk, nor can he reach your phone. This wasn’t a problem in the chat era, but in the task-execution era, this glass wall is the biggest obstacle.

Why was this wall always there, but only became a critical pain point in 2024? Because in the “chat” era, it didn’t matter at all. You asked AI to write a poem, solve a problem, translate a paragraph – it could do that with just the knowledge in its head. Connecting to external systems was optional. But once the goal changed to “getting things done for you”, the things behind the wall – your real data, the tools that can act – went from optional to absolutely necessary. The same wall, different requirements, completely different status. This is also why MCP arrived neither too early nor too late, but precisely at this pivotal moment.

1.2 The Birth of the Protocol: Anthropic Steps In

On November 25, 2024, Anthropic, the company behind Claude, launched and open-sourced MCP – a set of standards for AI applications to interact with external tools and data. Open source means the specification is public; anyone can see, use, and implement it, without fees or barriers.

Anthropic didn’t just throw out a document. On the same day, they released supporting SDKs (Software Development Kits) and a batch of pre-built connectors that could directly connect to common systems like Google Drive, Slack, GitHub, and Postgres databases. In other words, they prepared “how to use it” from the start, lowering the barrier to entry for everyone.

There is a noteworthy choice here: openness. Anthropic could have made MCP a private interface only usable by Claude, using it to lock in its users. It didn’t. Instead, it made the specification completely public, inviting everyone, including competitors, to use the same standard. This decision may seem like giving away their own advantage, but as we will see later, it is precisely the key step that allowed MCP to win. Let’s plant that seed here.

On the day of the release, a number of companies jumped on board – enterprises like Block and Apollo, and development tool teams like Zed, Replit, and Sourcegraph became early adopters. A new protocol, born and immediately used – that’s a good sign.

Let me clarify what open source means for a standard. It’s not just “the code is free to see”. It’s about putting the interpretation of the rules on the table: anyone can implement their own client and server without needing Anthropic’s approval, and without worrying about being charged or locked in one day. For something that aims to be a universal industry language, this kind of openness – “anyone can use, no one can change it for others” – is more effective than any marketing. It solves the trust issue first, and the only remaining question is whether the technology works well.

1.3 Twelve Months of Miracles: Even Competitors Adopted It

The real climax of this chapter is here. Generally, for a technical standard to become pervasive across an industry, it takes several years, sometimes even decades. Many underlying internet protocols took a generation to spread. MCP is different; it took about twelve months.

On March 26, 2025, the most critical piece fell into place: OpenAI officially adopted MCP. OpenAI is Anthropic’s most direct and biggest competitor; ChatGPT is its product. On that day, OpenAI CEO Sam Altman publicly stated on X that everyone loved MCP, they would support it in their own products, and immediately launched MCP support in OpenAI’s Agents SDK, with support for the ChatGPT desktop app and the Responses API to follow.

The significance of this event is: this is not a cooperation bought by Anthropic, nor a standard imposed by an industry association. It’s a competitor seeing the value clearly and proactively adopting rules set by its rival. A standard being willingly adopted by a mortal enemy is the strongest signal that it has transitioned from “a specific vendor’s proprietary thing” to “a true industry standard”.

Then came the chain reaction. In April 2025, Demis Hassabis, head of Google DeepMind, confirmed that the Gemini model would also support MCP. At Microsoft’s Build conference in May of the same year, Microsoft and GitHub also announced support for MCP, integrating it into the developer ecosystem. By the end of 2025, mainstream AI clients – ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor, VS Code – almost all natively supported MCP. In just one year, it went from a company’s proposal to a universal interface accepted by mainstream AI clients and developer tools.

Comparing it to standards that failed to spread reveals the key insight. Engineering history has no shortage of protocols that were technically superior but never took off. The common cause of failure was being tied to a single vendor, making others hesitant to adopt. MCP took the opposite approach: first, completely give away the specification, removing all concerns for everyone, and then use this safety net to secure widespread adoption. The fact that a competitor proactively used rules set by its rival is the hardest evidence that this strategy worked – no amount of advertising could buy that endorsement.

1.4 Handing Over to the Community: From One Company to Industry Infrastructure

The story has one final step. On December 9, 2025, Anthropic donated MCP to a newly established organization under the Linux Foundation called the Agentic AI Foundation.

This is a special interest fund hosted by the Linux Foundation. The founding parties include not only Anthropic but also Block and OpenAI, with backing from big companies like Google, Microsoft, AWS, Cloudflare, and Bloomberg. Along with MCP, Block’s goose project and OpenAI’s AGENTS.md specification were also donated, with MCP being the most significant piece. Anthropic specifically stated that MCP’s existing governance model, led by maintainers, would remain unchanged; the donation changes ownership, not daily operations.

Why would a company give away something it built with its own hands and that has become wildly popular across the industry? Because for something that aims to be a “standard”, being held by a single company is its biggest weakness. As long as it was “Anthropic’s MCP”, competitors would always have a lingering concern: what if you change the rules or restrict access tomorrow? Handing it over to a neutral foundation sends a clear message to the world: this is everyone’s utility, not a private asset. This step completes the narrative of “openness” that was planted in section 1.2.

This “build it big, then donate to a neutral foundation” script has precedents in the open-source world. After Google donated the container orchestration system Kubernetes to the Cloud Native Computing Foundation (CNCF), Kubernetes solidified its position as the industry standard, with all cloud providers confidently using it. The Linux Foundation has played this neutral custodian role for years, turning key technologies from private assets into public infrastructure. MCP entering the Agentic AI Foundation follows this proven path.

At this point, a question becomes irresistible: Why did it succeed so quickly? A standard making all competitors bow down in twelve months is extremely rare in history. The answer is not in this chapter; we must wait until we have explained what it is and who its predecessors are, before revealing it in Chapter 4.

2. What Exactly is MCP Doing?

The previous chapter covered MCP’s history. This chapter will explain MCP itself. There is only one rule: every jargon term will be accompanied by a real-life analogy. Not two terms thrown at you in a row. After reading this chapter, you should be able to explain what MCP is to a friend in one sentence.

2.1 The Real Problem: The N×M Problem

First, let’s clarify exactly what problem MCP is solving, otherwise the rest is castles in the air. This problem has a simple name: the N×M problem.

Imagine there are 10 AI applications on the market, like the Claude desktop app, Cursor, and various other AI assistants. (Let’s clarify one thing: GPT, Claude, Gemini are base models – the brains. The layer you actually interact with is the application wrapping the model.) On the other side, there are 100 tools and data sources waiting to be integrated – your calendar, your database, your company’s customer service system, GitHub. Before MCP, for every AI application to use every tool, someone had to write specialized integration code for each pair, commonly called a connector. 10 applications, each needing to connect to 100 tools individually. In the worst case, that’s 10 times 100 – a thousand sets of connectors.

Worse, these connectors are not interchangeable. The set written for one application cannot be used with another; it has to be rewritten. You connect your CRM today, then tomorrow you switch applications, and all that work is lost. Developers are trapped in a tangled web of connections, spending most of their effort on this uncreative, labor-intensive “connecting” work.

Let’s paint a concrete picture. An engineer wants their company’s AI assistant to be able to access the internal customer management system CRM. In the past, they had to write a custom plugin for that specific application, debug, test, and maintain it. This often took several days to a couple of weeks. Switching to another application, the whole thing started over. Multiply this repetitive labor across thousands of companies in the industry – it’s an astonishing waste.

MCP’s core value can be explained in one sentence: it straightens out this tangled web. What used to require N times M connectors now becomes N plus M. Each AI application only needs to learn MCP, this single “common language”. Each tool only needs to wrap itself once according to MCP’s rules. Both sides can then discover, describe, and invoke each other using the same process. That engineer writes one MCP server, and all MCP-supporting AI applications and clients can connect to his CRM. No more writing one client at a time.

I need to clarify the phrase “worst case”. In reality, not every application needs to connect to every tool. But as long as integrations are custom and not general-purpose, the total cost for the entire ecosystem grows multiplicatively with the number of applications and tools. Each new member on either side theoretically requires a whole new row of connectors to match it. This quadratic burden is the truly frightening part of the N×M problem: connecting a single tool isn’t much of a deal, but the industry’s total integration cost is locked into a curve that will only get heavier. What MCP does is change this curve from multiplicative to additive – a difference in magnitude.

2.2 An Analogy: The USB-C for AI

If the above is still a bit abstract, Anthropic itself provided a very fitting analogy. The official documentation literally says: Think of MCP as a USB-C port for AI applications.

Recall what it was like before USB-C. Phones, cameras, hard drives, headphones – each device had its own port and proprietary cable. You had to carry a bunch of chargers. If you lost one, you had to find the exact model. After USB-C unified the interface, one cable plugs into almost everything. No one needs to remember what port their device has.

MCP aims to be this USB-C for the AI world. Any AI application (the host) that adheres to this standard can plug into any tool (the server) that adheres to it. Plug it in, it works. It automatically recognizes what capabilities the tool has. No need to write custom code for each combination. One unified interface anchors the logic of this entire chapter.

This analogy is excellent because it conveniently highlights the essence of a standard: standards don’t create new capabilities; they eliminate repetitive work. USB-C didn’t make your hard drive faster; it just removed the headache of worrying about ports. Similarly, MCP doesn’t make models smarter; it makes the act of reaching things – from a difficult chore to a default capability.

This USB-C analogy also hides a layer of history worth noting. The proliferation of different ports wasn’t because manufacturers were stupid; it was because each wanted to use its own proprietary interface to lock in users and sell proprietary accessories. Whether a unified interface could succeed depended on whether companies were willing to abandon the “lock-in” mentality and accept a public standard that everyone could use. The technical difficulty was secondary. MCP faces the same hurdle. What’s most unusual about it is that precisely the AI companies that should be most guarded against each other chose to share a common port this time.

2.3 How MCP Works: Host, Client, Server

Let’s break down the analogy and look inside. MCP actually involves three roles working together. It’s easiest to explain with personification.

The first role is the host. This is the AI application you directly interact with – the Claude desktop app, Cursor, etc. Think of it as a project manager. It takes your commands, handles scheduling, but doesn’t do the legwork itself.

The second role is the client. The client lives inside the host and is the liaison sent out by the host. For every external tool it needs to connect to, the host dispatches a dedicated client to communicate one-on-one with that tool. One client per tool, no cross-talk. The client is like an assistant to the project manager, specifically responsible for interfacing with a particular external vendor.

The third role is the server. The server represents the tool or data source. Your Google Calendar has an MCP server. Your company’s database has one. GitHub has one. The job of each server is to clearly report what it can do in plain language: “I can look up calendar events, add events, delete meetings.” It’s like the receptionist sent by the vendor, specifically telling visitors what services their company provides.

The term “protocol” sounds intimidating, but stripped down, it’s just a set of pre-agreed rules for conversation among these three parties: how the liaison (client) should ask, what format the receptionist (server) should answer in, and how the project manager (host) should pass the response along. With unified rules, any host and any server can start talking on the spot, even if they’ve never met.

To be more detailed, the capabilities a server reports to the model are not just limited to one type. MCP splits what a server can provide into several categories: tools that the model can actively call (e.g., send email, query a database); resources that can be read (e.g., a document, a log file); and pre-defined prompt templates that help the model handle a common type of task efficiently. You don’t need to memorize these terms. Just know that a server is not just a row of “action buttons”. It can also pass along “readable materials” and “ready-made workflows”.

There is a deliberate design detail in this three-party division: the client and server have a strict one-to-one relationship. If a host wants to connect to ten tools, it dispatches ten clients inside itself, each unaware of the others, each managing its own connection. This is for isolation. If a tool you connect to malfunctions, it won’t affect other tools. Later, when we discuss security, we’ll see that this isolation is useful but cannot prevent all attacks.

2.4 A Walkthrough: AI Helps You Check Sales

Just looking at the roles is still dry. Let’s make these three parties go through a real scenario. Scene: You tell the AI assistant, “Help me check last month’s sales.”

Step 1: Discovery. The host sends a client to ask the company database server: “What can you do?” The server responds with a list in plain language: “I can query sales by month, split by region, export details.” Notice all of this is in natural language descriptions. The model reads this description to know what tools are available and what parameters each one needs.

Step 2: Invocation. The model thinks, “‘Query sales by month’ matches what I need.” So it instructs the client to call this tool, passing the parameter “last month”. This step is the model itself deciding which tool to use; you don’t have to point it out manually.

Step 3: Response. The server actually goes to the database, retrieves the numbers, and sends them back through the chain to the model. The model takes last month’s sales data and organizes it into a natural language reply: “Last month’s sales were X, an increase of Y% compared to the previous month.”

Throughout the whole process, you only said one sentence. Behind the scenes, the host, client, and server ran multiple rounds. The key point is that this process is the same for any tool. Today it’s checking sales, tomorrow it’s sending an email, editing a calendar event, or submitting code. Only the server changes; the rules remain the same. By now, you should be able to explain MCP to a friend in one sentence: It’s a unified set of rules that allows AI assistants to automatically discover and use external tools and data, without requiring manual integration for each tool.

Let me add a real-world complication: what happens when something goes wrong? In the real world, the database might be unavailable, permissions might be insufficient, or the model might pick the wrong tool. MCP’s process allows the server to report “This call failed because of reason X” back to the model. The model can then try a different tool or honestly tell you, “I couldn’t do it because I lack permission.” This is the most critical part after gaining hands and feet: when it succeeds, it really succeeds; when it fails, it tells you why, rather than fudging it.

Also, precisely because each action actually hits an external system, this mechanism is far more dangerous than simple chatting. Chatting can only produce wrong words; executing actions could delete a calendar entry you shouldn’t have deleted, or send an email you shouldn’t have sent. Capability and risk are two sides of the same coin. We’ll address this in Chapter 5.

3. This Shape Existed Long Before

MCP sounds new, but its “shape” is not new at all in engineering history. This chapter lists its predecessors from near to far. You’ll see that “using a common standard to turn a chaotic many-to-many mess into a simple many-plus-many arrangement” is a repeatedly recurring old pattern. Understanding this gives us coordinates for positioning MCP in Chapter 4.

3.1 The Closest Ancestor: LSP

The closest relative to MCP is LSP – the Language Server Protocol. This analogy gives the most bang for the buck, so let’s discuss it a bit more.

The problem LSP solves is almost identical to MCP’s, just in a different domain: code editors. Programmers use many editors: VS Code, Vim, various IDEs. There are also many programming languages: Python, Go, Rust. For each editor to intelligently support each language – with autocomplete, syntax error reporting, go-to-definition – in the past, it had to be written individually. M editors times N languages – again, that tangled mess of M×N, identical to the N×M problem in section 2.1.

In June 2016, Microsoft, along with Red Hat and Codenvy, standardized LSP, straightening this out. The language side only needed to implement one “language server”. The editor side only needed to speak LSP. They then matched up. N×M instantly collapsed to N+M: each editor written once, each language written once, done.

MCP’s relationship with LSP is a direct inspiration. The bloodline is traceable. MCP’s design directly reuses LSP’s message flow idea. Both use the same underlying message format, JSON-RPC 2.0, to send and receive requests. Essentially, Anthropic took the approach that LSP had validated and successfully run for nearly a decade in the “editor × language” domain and applied it to “AI application × tool”. The path was trodden by a predecessor; the follower saves countless trials and errors.

LSP also left behind a lesson that MCP inherited: let the standard only care about “how to talk”, not “what the specific capabilities are”. LSP never specifies what features a language should have. It only specifies the format for exchanging messages between editor and language server. Features like autocomplete, error reporting, and go-to-definition are implemented by each language itself. MCP is identical. It doesn’t decide what functions a tool should provide; it only sets the rules for information exchange among the three parties. This restraint – “only manage communication, not content” – is the key to such protocols being widely reusable. The less you manage, the more you can build on top of it.

3.2 Contemporary Cousins: Function Calling and ChatGPT Plugins

Slightly more recent relatives are two things OpenAI did in 2023. They aimed to solve the same problem as MCP but took a different path, and they serve as negative examples.

One is function calling, launched in June 2023. It allows developers to describe external functions to the model, and the model decides which to call and with what parameters. The other is ChatGPT Plugins, launched in March 2023, intended to be an “AI app store” where third parties could hang services as plugins on ChatGPT – book flights, order food, search papers.

The direction was right, but the problem was closure. Function calling and plugins were proprietary to OpenAI. The plugin you made for ChatGPT couldn’t be used by Claude or Gemini. Every new model required you to redo everything. The plugin path was even rougher; it had some buzz at first but quickly cooled down. OpenAI stopped new plugin sessions on March 19, 2024, and completely shut them down on April 9, 2024, replacing them with the broader Custom GPTs.

This comparison is very educational. A closed, single-vendor app store ultimately lost to an open, universally implementable protocol. Both aimed to connect AI to the external world, but the path that bet on “only I can use it” didn’t go far, while the path that bet on “everyone uses it together” survived. This reflects the value of the “openness” choice highlighted in section 1.2, casting its shadow in history.

The short-lived history of ChatGPT Plugins is especially worth mirroring. Launched in March 2023 with high hopes of becoming the AI-era app store, they fizzled out within a year. Besides being closed, there were other problems: developers had to specifically adapt for them; users had to manually install and enable each one, leading to a fragmented experience. What they could connect to and how many people they could reach were entirely constrained by OpenAI’s own pace. The successor, Custom GPTs, changed the form but not the core of “only playing in my ecosystem”. MCP completely reversed this: the protocol is open, anyone can make a server, any model can use it, and discovery and invocation are handled automatically by the model. The same goal, an open approach succeeded, a closed approach failed.

3.3 Older Engineering History: How Programs Talk

Let’s zoom out further. Having two programs talk to each other over a network is a problem computer science has been wrestling with for thirty years. MCP stands on the shoulders of a long line of predecessors.

The earliest was RPC (Remote Procedure Call), allowing a program on one machine to call functionality on another machine as if it were a local function. Later, around the year 2000, enterprise-level standards like SOAP and WSDL emerged. Their ambition was grand: to formalize and rigidly specify all cross-system communication. Surrounding SOAP was a large family of specifications starting with “WS-”: WS-Security for security, WS-Addressing for addressing, WS-ReliableMessaging for reliable transport. There was a long list of names, so the industry collectively called them the WS-* series (written as WS followed by an asterisk wildcard, representing this entire string of suffixes). However, this set of standards was overly specified, piled on top of each other, and the configuration files alone could make your head spin. It was heavy and hard to use, becoming a classic case study of “overdesign”.

As a counter-reaction, the popular REST came next, taking the opposite minimalist path, paired with OpenAPI to describe what an interface looked like. It was lightweight and easy to understand, becoming the mainstream for web services today. MCP is often compared to “OpenAPI for the AI era”. Both use a standard specification document to tell the other party “what capabilities I have and how to call them”. The difference is that OpenAPI is mainly written for humans and programs to read, while MCP is specifically designed for AI models to read.

In this decades-long thread, there is a swinging pendulum between “too loose” and “too tight”. RPC and early solutions were too loose – everyone did their own thing, leading to poor interoperability. SOAP and the WS-* generation overcorrected, making rules airtight and so heavy that no one wanted to use them. REST swung back to simplicity, winning the entire internet with a few simple conventions. Engineers in each generation have to re-find the balance between these two extremes.

MCP stands at the latest position of this pendulum. Its choice is clear: it would rather be simple, even if it doesn’t look “rigorous” enough, than be so complex that it scares developers away. It avoids the pitfall of WS-*’s “big and whole” approach and learns from REST’s restraint of “good enough”. Whether a standard survives often depends on how easy it is to get started. Comprehensiveness is secondary. History repeatedly shows that in this multiple-choice question, the simpler option almost always survives.

3.4 The Most Visual: Everyday Standards

Finally, let’s step out of software and look around us. “Using a common standard to bridge a bunch of incompatible things” – this pattern is everywhere in the physical world, and each time it has profoundly changed an industry.

• USB: Unified the interface for computer peripherals. U-disk, mouse, keyboard – plug and play. No more proprietary drivers for each device.
• Device drivers: Allowed operating systems to not have to write custom code for each printer model. Just recognize a common interface.
• Shipping containers: Standardized sizes. Cargo ships, trucks, cranes, trains – all designed around this one size. Global logistics costs dropped dramatically.
• Railway gauge: Standardized the distance between rails. A single train can run from one country to another.

You never think about these things in daily life, but without them, the whole world would grind to a halt. They all point to a deep rule: the universal adapter is a recurring old pattern. Whenever the contradiction of “more and more things, but they can’t talk to each other” accumulates to a critical point in a domain, a unified standard emerges to turn chaos into order, and then triggers a wave of growth that was previously suppressed by integration costs. MCP is the latest example of this old pattern in the AI era.

Looking more closely at these everyday standards, their payoff structure is also surprisingly consistent: in the short term, they save integration trouble; in the long term, they enable entirely new businesses that didn’t exist before. After container standardization, the savings weren’t just in loading and unloading fees. It directly made global supply chains, ocean shipping, and multinational manufacturing possible, redrawing the entire world’s economic map. After USB became widespread, a large number of small hardware vendors emerged that could only survive because of this unified interface. The true power of a unified standard is never in the little bit of money saved, but in the new space it unlocks – space that could not exist before. Keep this in mind; it will be useful when we assess MCP’s significance in Chapter 4.

4. Where Does MCP Fit In?

Chapter 3 lined up the predecessors. This chapter positions MCP: where exactly does it fit in this family tree, and why could it succeed so quickly? First, we solve the mystery left from Chapter 1, then we assess its weight within that century-old pattern.

4.1 Solving the Mystery: Why Did MCP Succeed So Quickly?

Let’s return to the question posed at the end of Chapter 1: How could a protocol make all competitors bow down in twelve months? The answer is three things coming together, none of which could be missing.

First, openness. Anthropic made MCP completely open, free, and not tied to its own product from the start. Later, it even donated it to a neutral foundation. This step eliminated all concerns for competitors to adopt it. Think about it: if MCP was only usable with Claude, OpenAI would never have voluntarily connected to it in March 2025. At best, it would have been an internal Anthropic feature, never catching fire outside its own yard.

Second, simplicity. It learned from LSP and REST’s path of restraint. It didn’t go down the WS-* road of “big and all-encompassing”. It reused the mature JSON-RPC under the hood. Tool descriptions are in plain language. A developer can get a server running in an hour or two. The easier a standard is to start with, the faster it spreads – an iron law repeatedly proven by countless predecessors.

Third, timing. MCP appeared at the end of 2024, precisely riding the wave of AI transitioning from “chatting” to “wanting to do things”. Two years earlier, models were still stuck in dialog boxes. There was no urgent need for such an integration standard. Even the best protocol would have gone unnoticed. Two years later, various companies might have already built a bunch of incompatible wheels, making unification much harder. MCP arrived neither too early nor too late – exactly at the moment the entire industry needed it most.

• Openness gave it the qualification to be accepted.
• Simplicity gave it the speed of diffusion.
• Timing gave it the exploding demand.

All three combined created this twelve-month miracle.

None of these three can be missing, and this point is worth pausing over. Openness alone is not enough: an open but hard-to-use protocol won’t get any traction. Simplicity alone is not enough: a simple but single-vendor interface, even if competitors like it, they might hesitate because of the lock-in risk. Just good timing is even less: demand arrives, but if the thing is both hard to use and closed, some other solution will take its place. MCP’s luck is that all three things happened to be in place simultaneously and they reinforced each other: openness reduced concerns, simplicity accelerated spread, and timing amplified demand – three forces twisted into one rope. Most technologies only have one or two of these, so they buzz for a while and then fade away. This is also why cases where “all three are present” are so rare.

4.2 The Universal Adapter: A Century-Old Pattern

Putting MCP into the big pattern from section 3.4, its historical positioning becomes clear: it is the latest example of the century-old “universal adapter” pattern. In terms of originality, it’s not groundbreaking. In terms of significance, it might be underestimated.

Each time this pattern appears, the script is roughly the same. First, a domain accumulates more and more things that don’t talk to each other, and integration costs become a headache for everyone. Then, a unified standard emerges, straightening the many-to-many mess into many-plus-many. Finally, the demand that was previously suppressed by integration costs explodes, triggering a wave of growth. Containers for global trade, USB for personal computers – both followed this script.

MCP is standing between act two and act three of this script. It has already straightened the messy web of connecting tools to AI. What’s likely to follow is an explosion of applications: when the cost of adding a new capability for AI drops from “days to weeks” down to “write once, use everywhere”, countless small tools and integrations that were too troublesome to build before will pop up like mushrooms. Every time a universal adapter has appeared in history, it has been followed by this kind of boom, ignited by a dramatic drop in cost.

Therefore, when positioning MCP, don’t get hung up on what novel thing it invented. It doesn’t win on originality. Its significance lies in the fact that it applied a time-tested, old solution in the right place at the right time.

Let me fully elaborate this point: originality and importance are two different things. Technically, MCP almost didn’t invent any new wheels. JSON-RPC already existed. The N+M idea was used by LSP. The open governance game was demonstrated by Kubernetes. But it is precisely this “recombination of all mature parts” that makes it exceptionally stable and fast. It doesn’t have to bet on any untested new technology. Every part has been running well elsewhere for years. Matching a real demand at a turning point with a zero-risk, mature solution – the destructive power of such a combination is often greater than a solitary genius invention.

4.3 The Best Standards Eventually Disappear

Finally, let me give you a yardstick to measure whether a standard like MCP has truly succeeded. This yardstick is a bit counterintuitive: the most successful standards eventually become things no one talks about.

Think about USB-C. When it first came out, it was hot tech news. Today, when you plug in a charging cable, you don’t even think about the words “USB-C”. It has faded into daily life, becoming something you take for granted. TCP/IP underpins the entire internet, but besides engineers, nobody thinks about it while scrolling on their phone. The sign that a standard has truly won is when it goes from being a topic to being like air – from “amazing new technology” to “the default utility”. You don’t thank USB-C every day, and that precisely proves its complete success.

By this yardstick, MCP is rapidly moving towards “invisibility”. As of December 2025, its SDK has over 97 million monthly downloads, and there are over 10,000 active public servers across the web. Behind these numbers are countless developers who have already made it the default choice, using it to connect tools without considering it something worth discussing.

This is MCP’s current historical position: it is in the process of sinking from “hot topic” to “invisible infrastructure”. The next generation of AI software that can do