What Is Model Context Protocol (MCP) — And Why It's Being Called USB-C for AI

Your LLM is smart. But without a way to talk to the outside world, it's smart in a locked room.

---

The Tool That Can't Use Any Tools

You've built something cool — an AI assistant that answers questions about your codebase. You wire it up to GPT or Claude, feed it your docs, and it works. Then someone asks: "Can it also create a Jira ticket when it finds a bug?" Sure, you think. You write a custom integration. Then: "Can it also read from our Postgres database?" Another custom connector. "What about Slack notifications?" Another one.

Three weeks later, you're not building an AI product anymore. You're maintaining a pile of glue code — one fragile connector for every tool your AI needs to talk to. Each one has its own auth flow, its own data format, its own failure modes. And every time you switch to a different LLM provider, half of them break.

This is the reality most developers building with LLMs hit. The model itself is the easy part. Connecting it to the real world? That's where things fall apart.

Why Should You Care?

If you're building anything beyond a simple chatbot — an AI coding assistant, an internal knowledge tool, an automated workflow — you're going to run into this integration wall. And if you're interviewing at companies working on AI products (which is... most companies now), understanding how AI agents connect to external tools is the kind of systems-level thinking that separates strong candidates from prompt-wrapper builders.

Model Context Protocol, or MCP, is the industry's answer to this mess. And it's worth understanding now, because it's quickly becoming the standard way AI agents interact with the world.

Let Me Back Up — What Is MCP, Really?

MCP is an open protocol, originally created by Anthropic in late 2024 and now governed by the Linux Foundation. It standardizes how AI applications discover, connect to, and use external tools and data sources.

The analogy everyone uses is USB-C — and it's actually pretty accurate. Before USB-C, you had a different cable for every device. Micro-USB for your phone, Lightning for your iPad, some weird barrel connector for your laptop. USB-C said: one port, one standard, everything connects.

MCP does the same thing for AI integrations. Instead of building a custom connector for every tool (GitHub, Slack, databases, file systems, APIs), you build one MCP server for each tool, and any MCP-compatible AI client can use it.

Before MCP: every AI app needs custom integration code for every tool. N apps times M tools = a mess.

After MCP: each tool exposes one standard server. Any AI app can connect using the same protocol.

That "N times M" problem — where N AI apps each need M custom integrations — becomes "N plus M." Each tool has one MCP server. Each AI app speaks MCP. Done.

Okay, But How Does It Actually Work?

MCP uses a client-host-server architecture. Let's trace through it step by step, like a request flowing through the system.

The Three Players

Host — This is the AI application your user interacts with. Think of it as the main app: a chatbot UI, a coding IDE with AI features, or a custom internal tool. The host contains the LLM and orchestrates everything.

Client — The client lives inside the host. It's the piece that knows how to speak the MCP protocol. When the LLM decides it needs to use an external tool, the client formats that request into a standard MCP message and sends it to the right server. One host can have multiple clients, but each client talks to exactly one server.

Server — The server is the external service that actually does the work. It connects to a specific tool — your file system, a database, an API — and exposes that tool's capabilities in a format the LLM can understand.

The client-host-server flow: the host orchestrates, clients speak MCP, servers do the actual work.

The Three Primitives

Every MCP server exposes its capabilities through three types of things:

Tools — These are actions the AI can execute. Think "create a file," "query the database," "send a message." Tools have defined inputs and outputs, so the LLM knows exactly what parameters to pass and what to expect back. This is the most common primitive — it's what makes AI agents actually do things.

Resources — These are read-only data sources. File contents, database rows, API responses, log files. The AI can read them but not modify them through this primitive. Think of resources as the context the AI pulls in to make better decisions.

Prompts — These are pre-written templates that help the AI use the server effectively. They're like instruction manuals that tell the LLM: "When using this tool, here's the best way to structure your request."

Under the hood, all of this is transported over JSON-RPC 2.0 — the same message format used by the Language Server Protocol that powers code editors like VS Code. If you've ever used Go-to-Definition or auto-complete in your IDE, you've already used a protocol built on similar ideas.

What a Real Flow Looks Like

Here's what happens when you ask your AI assistant to "find all open bugs assigned to me in GitHub":

1. The host receives your message and sends it to the LLM
2. The LLM decides it needs the GitHub tool and outputs a tool call
3. The MCP client formats this as a JSON-RPC request and sends it to the GitHub MCP server
4. The server authenticates with GitHub's API, fetches your assigned issues, and returns the data
5. The client passes the data back to the LLM
6. The LLM generates a natural language response with your bug list

The key thing here: the LLM didn't need to know anything about GitHub's API. It just knew "there's a tool called list_issues that takes an assignee parameter." MCP handled the rest.

Who's Actually Using This?

This isn't a whitepaper that nobody adopted. MCP has serious momentum. Anthropic created it, then donated it to the Linux Foundation's Agentic AI Foundation in late 2025 — co-founded with OpenAI and Block (the company behind Square). That means the two biggest AI labs are both backing this standard.

SDKs exist for Python, TypeScript, C#, and Java. OpenAI's Agents SDK has native MCP support. Microsoft Azure has MCP templates. Red Hat is integrating it into OpenShift AI. There are already thousands of community-built MCP servers for everything from Kubernetes to Notion to local file systems.

The pattern that's emerging in production systems is the MCP Gateway — a single endpoint that your AI agent talks to, which routes requests to the right MCP servers behind the scenes. It handles auth, logging, and rate limiting in one place, rather than scattering that logic across every server.

Mistakes That Bite — Common Misconceptions About MCP

"MCP replaces RAG." Nope. They solve different problems. RAG is about giving an LLM the right knowledge at the right time — retrieving relevant documents and stuffing them into the context window. MCP is about letting the LLM take actions and access live data. A production AI system often uses both: RAG for knowledge enrichment, MCP for tool orchestration.

"MCP is just function calling with extra steps." This one's understandable. MCP does build on top of function calling — the LLM still decides to call a tool and passes parameters. But function calling alone doesn't solve discovery (how does the LLM know what tools exist?), standardization (every provider does it differently), or lifecycle management (connecting, disconnecting, error handling). MCP wraps all of that into a protocol.

"It's only for big companies." MCP servers are lightweight. You can build one in an afternoon. The mcp-agent framework from LastMile AI is literally designed around the idea that "MCP is all you need" to build agents. For a side project or hackathon, spinning up an MCP server that wraps your school's internal API would be a genuinely impressive demo.

Now Go Break Something — Where to Go from Here

If you want to get hands-on with MCP, here's a solid weekend path:

• Start with the official docs at modelcontextprotocol.io — they're surprisingly well-written and include quickstart guides for both Python and TypeScript.
• Take the free Hugging Face MCP course — it walks you through building MCP servers and connecting them to agents, with hands-on exercises.
• Try the mcp-agent framework on GitHub (lastmile-ai/mcp-agent) — it abstracts away the boilerplate and lets you focus on what your agent actually does.
• Build a simple MCP server that wraps an API you already use — maybe your college's timetable system, a weather API, or a local file search. Then connect it to Claude Desktop or any MCP-compatible client and watch your LLM suddenly become useful in the real world.

For deeper reading, search for "MCP Gateway patterns" — this is the production architecture pattern that's emerging for managing multiple MCP servers at scale, and it's the kind of systems design knowledge that shows up in interviews.

---

Remember that pile of glue code — one custom connector for every tool, breaking every time you switch providers? MCP doesn't eliminate the work of integrating tools, but it gives you a standard to build against. One protocol, one message format, any AI client. Your LLM was smart before. Now it has hands.