If you’ve been anywhere near the AI developer world lately, you’ve probably seen three letters popping up everywhere: MCP. Maybe you saw it in a tweet. Maybe your coworker mentioned it. Maybe you saw it in some tool’s changelog.
By the end of this post, you’ll understand what MCP is, why it exists, and why it actually matters to you as a developer. Just the stuff you need to know.
So… What Actually Is MCP?
MCP stands for Model Context Protocol. It’s an open standard created by Anthropic (the company behind Claude) that was released in November 2024.
Here’s the one-line version:
Think of it like USB. Before USB existed, every device had its own unique connector. Your printer had one cable, your keyboard had another, your camera had yet another. It was a mess. USB came along and said, “Hey, let’s all just agree on one standard plug.” Suddenly everything worked with everything.
MCP is trying to do the same thing, but for AI. Instead of every AI app needing a custom-built connection to every tool and database, MCP gives everyone a shared language to communicate.
Why Does This Even Need to Exist?
Here’s the problem MCP solves. Imagine you’re building an AI assistant for your company. You want it to:
- Read files from Google Drive
- Pull data from your Postgres database
- Post messages to Slack
- Check GitHub issues
Without MCP, you’d need to write a separate, custom integration for each one of those. Four tools means four different connectors with four different patterns. Now imagine you want to switch from one AI model to another. Guess what? You might need to rewrite all four integrations.
This is what developers call the N×M problem. If you have N AI apps and M tools, you end up building N times M custom connections. It doesn’t scale. It’s fragile. And it’s a massive waste of time.
N AI apps × M tools → many fragile integrations
After MCP:
N + M → shared connections
MCP flips this into an N+M problem. Each AI app implements MCP once. Each tool implements MCP once. And now they all work together. Add a new tool? Every AI app that speaks MCP can already use it. Add a new AI app? It can already talk to every MCP-compatible tool.
That’s a big deal.
The “Before and After” Picture
Before MCP:
Your AI app needs Google Drive access → you build a custom Google Drive connector.
Your AI app needs Slack access → you build a custom Slack connector.
A different AI app also needs Slack → it builds its own custom Slack connector.
Everyone is building the same things over and over.
After MCP:
Someone builds an MCP server for Google Drive. Someone builds one for Slack. Now any AI app that speaks MCP can use both of them. No duplicate work. No reinventing the wheel.
The Three Key Players
MCP has a simple architecture with three main roles.
1. The Host
This is the AI application that your user actually interacts with.
2. The Client
This lives inside the host and speaks the MCP protocol.
3. The Server
This connects to tools and data sources.
A real-world flow looks like this:
- You ask Claude: “What are the open issues in our main repo?”
- Claude realizes it needs external data.
- The MCP client connects to the GitHub MCP server.
- The server calls the GitHub API and returns results.
- Claude answers with proper context.
The Three Things an MCP Server Can Offer
Tools — actions the AI can take
Resources — data the AI can read
Prompts — structured templates
Not every server needs all three.
How Is This Different From Function Calling?
Function calling is provider-specific and tied to one model integration.
MCP is a protocol.
Build an MCP server once, and multiple AI systems can use it.
Where Did MCP Come From?
Inspired by the Language Server Protocol (LSP), which allowed editors to support many languages without custom plugins.
MCP applies the same idea to AI and tools.
Should You Care?
If you’re building AI apps — fewer integrations.
If you’re building tools — broader compatibility.
What’s Next?
In the next post, we’ll go deeper into how data flows through an MCP system.