Why MCP Was Created: Problems Before Model Context Protocol

Think of a living room in Indore with a TV, a set-top box, an AC and a soundbar. Each one came with its own remote. A "universal" remote helps only if somebody has typed in a code for every brand, and when the soundbar company changes its codes, the universal remote quietly stops working for that device.

Then the devices start speaking a common standard over HDMI. Plug in a new soundbar and the TV remote can control it straight away, because the soundbar announces what it can do: volume, mute, input. Nobody types in codes any more.

The introduction to MCP explained what the protocol is. This article covers why it had to exist, which problems shaped its design, and how it has changed since launch.

Why was MCP created?

Map the living room to software. The remotes are AI applications: chat assistants, IDEs and agents. The devices are tools and data sources such as a database, a ticket system or a folder of PDFs. The codes typed into the universal remote are hand-written connectors. The HDMI standard, where devices announce their own functions, is MCP.

MCP was created to replace one-off connectors between AI applications and external tools with one open protocol, so a tool written once works in every compatible app and the app can discover at runtime what the tool offers.

Anthropic announced it on 25 November 2024 with the specification, SDKs and a set of reference servers. The announcement named the core issue directly: even capable models were cut off from data, and every new data source needed its own custom implementation.

What did AI integrations look like before MCP?

Before MCP, teams connected models to the outside world in four common ways. Each worked for one product and broke down across many.

Function calling deserves a closer look, because people often think MCP replaced it. It did not. Function calling is how a model asks for a tool. MCP is how an application finds and reaches the tool. The two work together, and MCP vs function calling shows exactly where one ends and the other begins.

The problems that shaped MCP's design

When the tool renamed a field, every hand-written connector broke separately. With a server, the fix happens once.

Problem 1: duplicated glue code

Picture three internal apps at a company: an HR chatbot, an IT helpdesk agent and a coding assistant. All three need the leave-balance system. Without a standard, three teams write three connectors with three sets of auth code, three retry policies and three sets of bugs.

Problem 2: silent drift

Duplication costs you once. Drift costs you every month after. When the leave system renames emp_id to employee_id, each connector fails on its own schedule, and you often find out only when a user complains. The simulation below shows the difference.

# The tool's API changed: "emp_id" became "employee_id".
def leave_api(params):
    if "employee_id" not in params:
        return {"error": "missing employee_id"}
    return {"days_left": 9}

# Before MCP: each app hard-codes its own copy of the request format.
apps = {"hr_bot": "emp_id", "helpdesk": "emp_id", "code_assistant": "emp_id"}
broken = [app for app, field in apps.items() if "error" in leave_api({field: "E42"})]
print("Before MCP, apps broken by one rename:", broken)
print("Fixes needed:", len(broken))

# With MCP: apps call a tool by name; only the server knows the API format.
def mcp_server_tool(arguments):              # the server team updates this once
    return leave_api({"employee_id": arguments["employee"]})

results = {app: mcp_server_tool({"employee": "E42"}) for app in apps}
print("\nWith MCP, results:", results)
print("Fixes needed: 1 (inside the server)")

The tool name and its input schema form a contract owned by the server team. The apps depend on that contract, not on the private details of the leave API underneath.

Problem 3: no runtime discovery

A hard-coded connector knows only what its author knew on the day it was written. If the leave system adds a "cancel leave" action, no app can use it until someone ships new code. MCP servers list their tools with descriptions and input schemas when asked, so an app learns about a new capability the next time it lists tools.

# A client that discovers capabilities instead of hard-coding them.
server_v1 = [{"name": "get_leave_balance", "description": "Days of leave left"}]
server_v2 = server_v1 + [{"name": "cancel_leave", "description": "Cancel a pending leave request"}]

def plan(user_request, tools):
    words = set(user_request.lower().split())
    scores = {t["name"]: len(words & set(t["description"].lower().split())) for t in tools}
    best = max(scores, key=scores.get)
    return best, scores

request = "please cancel my leave for Friday"
print("Using server v1:", plan(request, server_v1))
print("Using server v2:", plan(request, server_v2))

With v1 the closest match is the balance tool, which cannot cancel anything. With v2 the same client finds cancel_leave, and not one line of client code changed. That is the point of discovery. A real host lets the model choose rather than counting words.

Problem 4: local data and remote services needed one model

Some context lives on your laptop: a project folder or a local database. Some lives in the cloud: a CRM or a payments API. Earlier approaches usually handled one of the two well.

MCP defined two transports from the start, a local subprocess talking over standard input and output, and an HTTP transport for remote servers. The same messages travel over both.

Problem 5: consent was left to chance

When a connector lives inside an app, nothing tells the user which actions it can take. MCP made the host application responsible for showing what is exposed and asking before tools run. The current spec says hosts must get explicit user consent before invoking any tool. MCP security best practices explains how to build that properly.

Where did the idea for MCP come from?

MCP's design borrows openly from the Language Server Protocol (LSP), which the MCP specification cites as its inspiration. Before LSP, every code editor needed its own plugin for every programming language. LSP let one language server serve every editor.

MCP copies three ideas from LSP:

1. A client and server split. The app holds the client; the tool runs as a server, often as a separate process.
2. JSON-RPC 2.0 messages. These are simple request, response and notification objects that any language can produce.
3. Capability declarations. Each side states what it supports, so features can be added without breaking older peers.

How has the MCP specification changed since 2024?

MCP versions are dates. Each revision fixed problems people hit while running the previous one in production.

Five revisions in under two years. Each change came from problems seen in real deployments.

The latest change matters most if you learned MCP from older material. Up to 2025-11-25, a client opened a session with an initialize handshake.

From 2026-07-28, every request carries its own protocol version and client capabilities, so any server instance can answer any request. That makes servers far easier to run behind a load balancer. See the 2026-07-28 changelog for the full list.

Governance changed too. In December 2025 the Linux Foundation formed the Agentic AI Foundation, and Anthropic contributed MCP to it as a founding project. The protocol now has a neutral home, and its existing maintainers still steer it.

What MCP does not solve

• It does not make the model smarter. A model can still pick the wrong tool or pass bad arguments. Clear tool design matters, and avoiding tool overload covers it.
• It does not make a server trustworthy. A malicious server can speak perfect MCP.
• It is not an agent framework. MCP moves messages. Planning, memory and retries belong to your AI agent.
• It does not replace your APIs. Most MCP servers wrap an existing REST API, as MCP vs REST API explains.

Common mistakes when explaining why MCP exists

• "MCP replaced function calling." No. The model still uses function calling; MCP supplies the tools behind it.
• "MCP is a product from one vendor." It is an open specification with open-source SDKs, now under a Linux Foundation fund.
• "Old tutorials still apply word for word." Code that sends initialize targets 2025-11-25 or earlier. Check the protocol version a tutorial targets.
• "A standard removes integration work." Someone still writes each server once. MCP removes the repeated work, not all of it.

Key takeaways

• Before MCP, every app kept its own connector for every tool, which multiplied code and caused silent drift.
• MCP makes the server the single owner of a tool's contract, and lets clients discover tools at runtime.
• The design follows LSP: a client and server split, JSON-RPC 2.0 and capability declarations.
• Stdio and HTTP transports covered local and remote tools from the first release.
• The current revision, 2026-07-28, is stateless. Treat initialize-based examples as legacy.