Learn MCP - History, Background & Why MCP Is Needed

#Introduction

In episode 0 we set up the environment: Node.js, Python, the official SDKs, and the MCP Inspector. If you installed the SDK via npm install @modelcontextprotocol/sdk and haven't experimented yet, that's fine — right now we're taking a brief pause from the hands-on work to understand why MCP exists.

A protocol's history and background may seem unimportant, yet that's exactly where its design decisions live — including why MCP exists as an open, JSON-RPC-based standard. Understanding its origins will explain a lot: why MCP became a bidirectional standard (LLM to tool and tool to LLM), and why the specification keeps evolving.

#The Beginning: Anthropic's Announcement (November 2024)

MCP's story starts on 2024-11-05, when Anthropic announced MCP as an open protocol for connecting AI applications with external data and tools. Alongside the announcement, Anthropic released SDKs for TypeScript and Python and brought on several early partners such as Block and Apollo.

The key word from day one: open. MCP is not a Claude-specific protocol — it was designed so that anyone could build servers, and models from any vendor could use them. This principle of openness is what kept it alive as many vendors began to take notice.

That announcement also marked a turning point in how the community builds AI integrations: from the one application, one connector pattern toward one protocol, many servers. Two months later, dozens of community servers had already emerged — a sign that the need for this standard was real.

#The Problem MCP Solves

#Fragmented Custom Integrations

Before MCP, every AI application wrote custom integrations for every tool. Want to give the model access to a database? Write your own connector. Want access to Slack? Write another one. Each integration was a set of hardcoded code used by only one application — a big problem when applications changed.

The result: fragmented integrations. Every vendor spent time building the same thing over and over, and models couldn't move between applications without their integrations being rewritten. MCP emerged to break this cycle.

#One Universal Standard, Bidirectional Communication

MCP replaces that chaos with one universal standard: one way for LLMs to access data and tools. That's what sets MCP apart from ordinary tool-calling protocols:

With this pattern, the same MCP server can be used by many hosts without a hardcoded integration per application. You write a server once, and any application that understands MCP can use it immediately.

Imagine a server exposing a get_weather tool. In the pre-MCP world, each application (chatbot A, assistant B, CLI agent C) had to write its own connector. With MCP, all three simply call the same method:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Jakarta" }
  }
}

This identical request works for any application that understands MCP. That's where the power of the standard lies: one common language, many users.

#Widespread Adoption Across the Ecosystem

News of this openness spread quickly. By 2025, more than 1000+ MCP servers were listed in community registries, and major platforms joined in:

• OpenAI added MCP support in ChatGPT and its SDKs.
• Google supports MCP in Gemini and builds remote MCP servers.
• Microsoft uses MCP in Copilot Studio and Azure AI Foundry.
• Developer tools such as GitHub, Slack, and Notion provide official MCP servers.

This adoption puts MCP in a unique position: a standard born from a single vendor that became the de-facto standard for agent-to-tools connections across the ecosystem.

Another interesting side effect of this adoption: because the specification is open, each vendor can translate it into their own idioms — OpenAI with its chat patterns, Google with the Gemini ecosystem, Microsoft with Copilot — without changing the core JSON-RPC format. If you build an MCP server once, it's immediately compatible with all those platforms.

#Why JSON-RPC

The most striking foundation choice is JSON-RPC 2.0. Why not plain REST or gRPC? The reasons are practical:

• Lightweight and universal. Request/response is pure JSON, human-readable, and easy to debug with the MCP Inspector.
• No vendor binding. JSON-RPC isn't tied to any language or framework; the official SDKs in TypeScript and Python use it, and implementations in other languages just follow the same contract.
• Symmetric. The symmetric request/response model suits bidirectional communication between host and server — not just a one-way API call.

This decision is what makes MCP implementable in almost any programming language, from TypeScript and Python to C#, Kotlin, Java, and Go.

#Specification Evolution

MCP didn't stay at version one. The specification has evolved through several important iterations:

The two most influential iterations: 2025-03-26, which introduced Streamable HTTP and OAuth 2.1 — the foundation for remote servers — and 2026-07-28, which reworked the protocol core to be stateless. We'll cover both in detail in episode 3.

#Why the World Needs MCP

In summary, there are three main reasons MCP is needed:

• Eliminating duplication. One integration is used by many hosts, not one integration per application-tool pair.
• Clear composition. Tools, resources, and prompts are exposed with a clear schema so models and hosts can understand a server's capabilities.
• Open standard. No vendor lock-in; the specification and SDKs can be inspected, contributed to, and implemented by anyone.

It's like USB for hardware, or JSON for data exchange: before a standard exists, everyone builds their own connector; once the standard exists, all devices connect without special adapters.

To make sure your SDK follows the latest specification, check the available SDK version:

npm view @modelcontextprotocol/sdk version

#Conclusion

In this episode 1, you've traced MCP's birth from Anthropic's announcement on 2024-11-05, understood the fragmented custom integration problem it set out to solve, seen widespread adoption across the OpenAI, Google, and Microsoft ecosystems, and followed the specification's evolution up to the stateless era of 2026-07-28.

Key takeaways:

• MCP was announced by Anthropic on 2024-11-05 as an open protocol.
• It answers the problem of fragmented integrations: one standard for bidirectional communication between LLMs and tools.
• It's widely adopted across ecosystems with 1000+ registered servers.
• Key iterations: 2025-03-26 (Streamable HTTP & OAuth 2.1) and 2026-07-28 (stateless core).
• There are two specification eras: legacy session-based and modern stateless.

In the next episode 2 we'll dissect the core concepts and main architecture of MCP — the roles of Host, Client, and Server, the three main primitives (tools, resources, prompts), deprecated primitives, and the transport options between Streamable HTTP, SSE, and stdio. See you in episode 2!