What Actually Is MCP? The Non-Marketing Explanation

I spent three straight hours last month trying to figure out what MCP actually is. Not how to use it — just what it is. Every blog post I found was either a press release from Anthropic or a Medium article that just rephrased it. "MCP is a universal open standard for connecting AI assistants to the systems where data lives." Cool. That tells me absolutely nothing.

I run mcp-find.org, a directory of 290+ MCP tools. I've been neck-deep in this ecosystem for about 6 months now. And honestly, it took me an embarrassingly long time to understand what MCP actually does versus what the marketing says it does. So here's my attempt at explaining it the way I wish someone had explained it to me — without the corporate fluff.

What MCP is NOT

Let me start with the confusion, because most people hit the same walls I did.

MCP is not an API. I know, I know — it looks like one. There are requests and responses, JSON is involved, and there are endpoints. But it's not an API in the way you'd think of a REST API or a GraphQL endpoint. When I first read the spec, I kept trying to map it to API concepts, but it just didn't click. An API is something you call directly. MCP is more like... a way for AI apps to discover and call things. The AI is in the middle. That distinction matters more than I initially thought.

It's also not a plugin system. This one tripped me up for weeks. I kept comparing it to ChatGPT plugins or VS Code extensions, and it's not that. Plugins are tightly coupled to one specific host application. An MCP server can work with Claude, with Cursor, with any client that speaks the protocol. The server doesn't care who's calling it.

And it's not an SDK, even though there is an SDK. The SDK is just a helper library. MCP itself is a protocol — a set of rules for how two pieces of software communicate, like HTTP, but for AI-to-tool communication. I spent 20 minutes on a Discord thread arguing with someone who kept calling it "Anthropic's SDK", and I wanted to throw my laptop.

OK, so what IS it then

The analogy that finally worked for me — and I'll admit it's not perfect — is USB-C.

Before USB-C, every device had its own connector. Your phone had a micro-USB port, your camera had a mini-USB port, and your laptop had some proprietary port. Every time you wanted to connect something, you needed the right cable. MCP aims to be the USB-C for AI tools — one standard way for any AI application to connect to any external tool or data source.

The reason this analogy isn't perfect is that USB-C is a physical connector and MCP is a communication protocol. But the problem it solves is the same: before MCP, if you wanted Claude to query your database, you had to build a custom integration specifically for Claude. If you also wanted GPT to query the same database, you had to build another custom integration. With MCP, you build one server that speaks the protocol, and any AI client can use it.

That clicked for me around month two. Before that, I was parroting Anthropic's talking points without really getting it.

The three concepts that confused me the most

Here's where I wasted the most time: Host, Client, and Server.

I'm going to start with the one that confused me the most: the difference between Host and Client. In most software, "client" and "host" are basically the same thing — the host runs the client. In MCP, they're technically separate concepts, and I spent an entire afternoon reading the spec trying to understand why.

Here's how I finally got it. When you open Claude Desktop and it connects to the MCP servers, it is the Host. It hosts the application you see and interact with. But inside Claude Desktop, there are Clients — one for each MCP server connection. So if you have Claude Desktop connected to a filesystem server and a database server, there's one Host (Claude Desktop) and two Clients (one talking to each server). The Host manages the Clients.

Why does this matter? For most people, it doesn't. If you're setting up MCP tools, you can treat Host and Client as the same thing, and you'll be fine. The distinction matters when you're building applications that manage multiple MCP connections — which is what I had to do for mcp-find.org while testing tools at scale.

Then there's the Server. This is the easier concept. A Server is just a program that exposes some capabilities — tools, data, prompts — through the MCP protocol. A filesystem server lets the AI read and write files. A database server lets the AI run queries. A Slack server lets the AI send messages. I've indexed over 290 of these on my site, and honestly, maybe 30 of them are actually worth using. The rest are proof-of-concepts or abandoned repos with no documentation.

The simplest possible example

If you've never touched MCP before, here's the fastest way to see it in action.

Install Claude Desktop (if you haven't already)

Find your config file — on macOS, it's at ~/Library/Application Support/Claude/claude_desktop_config.json

Add the filesystem server:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/Desktop"]
    }
  }
}

Restart Claude Desktop completely — not just close the window, actually quit the app.

Ask Claude: "What files are on my desktop?"

That's it. Claude can now see your files through MCP. The filesystem server is the MCP server, Claude Desktop is the Host, and a Client inside Claude Desktop manages that connection.

The whole thing took me about 15 minutes the first time, and about 10 of those minutes were spent wondering why it wasn't working (I hadn't fully quit the app).

What can MCP servers actually do?

MCP servers expose three types of capabilities. I'll be honest — most people only use one of them.

Tools are the main thing. A tool is a function that the AI can call. "Search for files matching this pattern." "Run this SQL query." "Send this Slack message." When people talk about MCP, they're usually talking about tools. Of the 290+ servers I've indexed on mcp-find.org, 95% of them expose only tools.

Resources are read-only data sources. Think of them like files the AI can read but not modify. A server might expose your database schema as a resource, so the AI knows what tables exist before it tries to query them. Resources are useful, but I rarely see them in the wild.

Prompts are pre-written prompt templates. A server can include prompt templates that help the AI use its tools more effectively. I've seen 5 servers that actually implement prompts. It's the most ignored feature in the spec.

Can we talk about the naming for a second?

"Model Context Protocol." I've been saying these three words for 6 months, and I still think it's a terrible name.

"Model" — OK, it's about AI models. Fine. "Context" — sure, it provides context to models. "Protocol" — yes, it's a protocol. But the combination tells you nothing about what it does. If you told a developer "I'm using Model Context Protocol," they would have zero idea what you're talking about. Compare that to "REST" — also a terrible name, but at least the acronym is short. MCP sounds like a government agency.

And then there's "MCP Server" — which in any other context means "the server for MCP", but in MCP it means "a server that speaks MCP." So when someone says "I set up an MCP server," you don't know whether they mean they set up the protocol's infrastructure or a tool that uses the protocol.

Anthropic, if you're reading this: the naming is actively hurting adoption. Half the confusion in Discord channels is people not understanding the terminology.

Where this is actually going

I started mcp-find.org to keep track of all the MCP servers being built. In October 2025, there were 40 worth tracking. Now there are 290+. The ecosystem is evolving, but it's growing in a specific way. Most new MCP servers are built by individual developers scratching their own itch. These single-purpose servers are actually the most useful ones. The ambitious ones that try to do everything tend to be buggy and unmaintained.

The biggest shift I've noticed is enterprise interest. Three months ago, nobody in my network was talking about MCP at work. Now I'm getting messages from people asking how to deploy MCP servers behind their company VPN with proper authentication. That's a good sign. But the tooling for enterprise deployment is still basically nonexistent.

The MCP SDK itself has gotten way better since v0.9. The TypeScript implementation is solid. The Python one is catching up. But there's still no official spec for authentication, which means every server handles auth differently. Or doesn't handle it at all. That keeps me up at night.

That's my understanding after 6 months of living in this ecosystem. I've probably gotten some of this wrong — my track record with MCP predictions is about 50/50. Ask me again in a few months, and I'll probably tell you something different.