MCP — The Why

I didn't go looking for MCP. I backed into it.

This post is about building intuition. Before we get into what MCP is or how to use it, I want you to feel the problem it solves — in your gut, not just your head. If you've ever spent more time feeding context to an AI than actually getting work done, you already know this problem. You just might not have a name for it yet.

For months my setup was the same ritual: a capable model in one window, and all my actual work — Jira tickets, a GitHub repo, a database, a Google Drive full of half-finished docs — in a dozen others. Every time I wanted the AI to do something with that work, I had to carry the context across by hand. Every new tool meant another custom integration — another set of auth logic, another data format, another thing to maintain. This is my write-up of those notes, plus what changed once I started running MCP servers in Claude Code myself.

First, the boom that started it

ChatGPT launched on Nov 30, 2022. It crossed a million users in five days, and a hundred million in two months. Nothing in consumer software had moved like that.

What followed came in two distinct waves.

Wave two is where the trouble started. Once the AI was doing real work, people wanted it to do that work with their actual stuff — and their actual stuff lived in a dozen different apps.

Living in five AI worlds

Here's the thing nobody designed on purpose: the AI in Notion couldn't talk to the AI in Slack. The coding assistant in VS Code knew nothing about the discussion happening in MS Teams. Everyone ended up juggling a handful of disconnected assistants, each smart, each on its own island.

What "context" actually means

Context is everything an AI can see when it generates a response. More formally: the information — conversation history, external documents, the lot — that the model uses to produce its answer. When you chat with ChatGPT, your past messages are the context.

Which sounds simple until you picture a real job. Take a software engineer. Their work is scattered across Jira, GitHub, MySQL, Slack, Google Drive — and the AI sits in the middle of all of it, able to see exactly none of it.

So how did we feed it the context? We pasted. By hand.

The copy-paste hell

This was my life for a good while, and the slide that called it "copy-paste hell" felt personally attacked. I was the integration. I'd copy a stack trace out of the terminal, paste it into a chat, paste back the schema, paste in the relevant file, ask one question — then do the whole dance again for the follow-up.

The first fix: function calling

In mid-2023, OpenAI shipped function calling, and the picture changed. Function calling is a way for an LLM to call external functions — instead of just answering, the model can say "run load_file("abc.txt") for me" and use the result.

Wrap a function so the model can call it and you've got a tool. Suddenly an LLM could reach a Weather API, a database, a GitHub repo. Cursor got filesystem access and code search. Perplexity got live web browsing. ChatGPT Plus and Claude grew real tool capabilities. Every serious AI product raced to add Salesforce connectors, Slack bots, Drive integrations, database query tools.

It genuinely felt like the answer. The AI was finally connected to the world.

The fix created a worse problem

Look closely at how those tools were built and the catch appears. Every AI product was building its own way to call every API. A chatbot needed a Jira tool, a Slack tool, a GitHub tool, a MySQL tool. The coding agent needed its own Jira tool, its own Slack tool. So did the analytics agent. Everybody re-implementing the same connectors, slightly differently, forever.

This is the integration problem, and it's the whole reason MCP exists. With N AI clients and M services, you're on the hook for N × M separate integrations — each with its own authentication, its own data format, its own error handling. A maintenance nightmare, fragmented security, and a pile of wasted cost and time.

Here's the part worth playing with. Drag the size of your stack up and watch the two numbers diverge — point-to-point integrations grow like a square, the MCP approach grows like a line:

That square-versus-line gap is the why of MCP. Everything else is detail.

Enter MCP

The Model Context Protocol does for AI-to-tool communication what a standard port did for hardware: instead of every device inventing its own plug, everyone agrees on one. MCP defines two roles — a client and a server — and a shared language between them.

One client can fan out to many servers, and one server can be reused by any client. That's the whole topology shift below — from a tangled mesh to a clean hub:

The server does the heavy lifting

This is the bit I underrated until I'd built one. The server owns all the painful, service-specific work — and the client never has to care:

MCP vs function calling vs an API

It's a fair question: isn't this just function calling with extra steps? The difference is where the work lives and who can reuse it. Function calling is per-app glue you keep rewriting. An MCP server is a standalone, reusable boundary — the client calls a tool by name, and the server is the one importing the SDK, holding the credentials, and talking to the real API.

# MCP client — the AI app just calls a tool by name
result = call_tool("get_weather", {"city": "London"})

# MCP server — wraps the service once, reusable by any client
from mcp.server import Server

server = Server("WeatherServer")

@server.tool("get_weather")
def get_weather(city: str):
    data = lookup_weather(city)          # auth, rate limits, parsing all live here
    return {"temperature": data["temp_c"], "condition": data["condition"]}

server.start()

In practice, hooking one up is mostly a config entry. I've now edited more claude_desktop_config.json files than I'd like to admit — point the client at a server command, restart, and the tools just show up. I've also stood up a couple of small servers of my own, and the mental model held: the server hides the mess, the client stays simple.

The payoff — and why it compounds

Add it up and you get the slide that made the whole trilogy worth watching:

And then it stops being about one team's tidy diagram and becomes a flywheel. More AI clients supporting MCP makes it more worthwhile for services to ship MCP servers. More servers available makes it more worthwhile for AI tools to support MCP. More adoption drives more standardisation, which drives more ecosystem value. The flip side is the part that made me pay attention: not supporting MCP increasingly means being cut off from a fast-growing ecosystem.

What I take away

The honest version: MCP isn't a clever new capability. It's the boring, correct decision to standardise the plug. Function calling already let a model reach the outside world — MCP just stopped every app from reinventing that reach, and turned a quadratic problem into a linear one.

I felt all three stages of this personally. I was the human API doing the copy-pasting. I bolted on tool after tool until the integrations sprawled. And then I started running MCP servers in Claude Code and the sprawl quietly went away — the same servers, reused everywhere.

There's a small loop-closing detail I like: this very post came out of an MCP pipeline. A OneNote server reached straight into my notebook, pulled the "MCP — The Why" page and its slides off the page, and handed them to the model to write up — no copy-paste, no carrying context by hand. The thing the protocol is for is exactly how the thing got made.

What's next — and how I closed the loop with my own MCP server

This is Part 1. In Part 2 — The What, I'll break down MCP's actual architecture: the protocol handshake, the three primitive types (tools, resources, prompts), and how a client and server negotiate capabilities. In Part 3 — The How, I'll walk through building and shipping MCP servers from scratch.

But I want to end this post with a preview — a real example that shows where all of this leads.

Remember the copy-paste problem from the top of this post? I was the human API carrying context between my tools and the AI. After understanding why MCP exists, I built a small MCP server to solve my own version of that exact problem.

That's the promise of MCP in one concrete example. The same server I built for OneNote works with Claude Code, with Claude Desktop, with any MCP-aware client — because the protocol is the same everywhere. I didn't build a "Claude plugin" or a "ChatGPT connector." I built one MCP server, and it works everywhere.

I'll walk through exactly how I built it in Part 3. For now, the takeaway is this: MCP doesn't give AI new abilities. It removes the thing that was stopping us from using the abilities it already had — the wall between the model and our work.

References and Resources

• Introducing the Model Context Protocol — Anthropic — the original announcement and the clearest statement of the "why".
• Model Context Protocol — official site & docs — specification, concepts, and the client/server SDKs.
• modelcontextprotocol on GitHub — the spec, reference servers, and SDKs in the open.
• Connect Claude Code to tools via MCP — Claude Docs — how to actually wire servers into your client (the claude_desktop_config.json side of things).

Massive Shoutout to CampusX

These notes started as scribbles alongside the CampusX "Model Context Protocol — The Why | MCP Trilogy" video. If you want the full narration and the live demos I've compressed into a sentence or two, that's where to go — the same channel I credited in my Skills in Claude Code and Gen AI without the Hype posts. Still the clearest walk-throughs of fast-moving AI tooling I've found. Subscribe to the CampusX YouTube channel if any of this landed.