MCP: The USB-C of AI

Capsule description

You already know the M×N problem — every AI host needs custom integrations with every service. Now you're going to meet the solution: Model Context Protocol (MCP), an open protocol that standardizes how AI hosts connect with external services. MCP reduces the M×N problem to M+N, exactly as USB-C reduced the explosion of connectors in hardware.

In this capsule you're going to understand what MCP is, how it works at a high level, and why the USB-C analogy is more than a metaphor — it's the same standardization pattern applied to a different domain. By the end, you'll be able to explain MCP to any fellow developer in less than a minute.

The USB-C analogy: from M×N to M+N

Before USB-C (the problem)

In 2010, every manufacturer had its own connector:

Apple:
├── iPhone      → Lightning
├── MacBook     → MagSafe
└── iPad (old)  → 30-pin connector

Samsung:
├── Galaxy      → Micro-USB
└── Tablets     → Micro-USB 3.0

Others:
├── Nokia       → Proprietary connector (DC-4)
├── Sony        → Proprietary connector
├── Laptops     → Barrel jack (different per brand)
└── Cameras     → Mini-USB

Result: A drawer full of cables. 5 devices = 5 different cables. And if your friend has a Samsung and you have an iPhone, you couldn't share a charger.

That's M×N: M devices × N connector types.

After USB-C (the solution)

Apple:
├── iPhone 15+  → USB-C ✅
├── MacBook     → USB-C ✅
└── iPad        → USB-C ✅

Samsung:
├── Galaxy      → USB-C ✅
└── Tablets     → USB-C ✅

Everyone else:
├── Laptops     → USB-C ✅
├── Cameras     → USB-C ✅
├── Headphones  → USB-C ✅
└── Nintendo    → USB-C ✅

Result: A single cable works with everything. Your charger charges any device. Your cable transfers data from any source.

That's M+N: Every device implements USB-C (M implementations) and every accessory supports USB-C (N implementations). Total: M + N, not M × N.

Mapping USB-C to MCP

The key: Just as USB-C defines a standard that any device and accessory can implement, MCP defines a standard that any AI host and service can implement.

What exactly is MCP?

One-sentence definition

MCP (Model Context Protocol) is an open protocol that standardizes how AI applications connect with external data sources and tools.

Expanded definition

MCP defines:

1. How an AI host discovers what a service can do (capabilities discovery)
2. How they communicate — AI host and service (message protocol)
3. What types of things a service can expose (3 primitives: Resources, Tools, Prompts)
4. How permissions and security are handled

Think of MCP as a contract:

MCP Contract:

"If you're an AI host (Claude Code, Cursor, etc.):
 → Implement an MCP Client
 → You'll be able to connect with ANY MCP Server

If you're a service (GitHub, PostgreSQL, etc.):
 → Implement an MCP Server
 → ANY AI host with an MCP Client will be able to use you

Both sides speak the same protocol.
They don't need to know each other in advance."

How MCP solves the M×N problem

Without MCP: specific integrations

Claude Code ←[custom A]→ GitHub
Claude Code ←[custom B]→ PostgreSQL
Claude Code ←[custom C]→ Slack
Cursor      ←[custom D]→ GitHub      ← Different from A
Cursor      ←[custom E]→ PostgreSQL  ← Different from B
Cursor      ←[custom F]→ Slack       ← Different from C

Total: 6 custom integrations (3 hosts × 2... or M × N)

With MCP: standard protocol

Claude Code ←[MCP Client]→ MCP Protocol ←[MCP Server]→ GitHub
                                         ←[MCP Server]→ PostgreSQL
                                         ←[MCP Server]→ Slack
Cursor      ←[MCP Client]→ MCP Protocol ←[same MCP Servers]→
Windsurf    ←[MCP Client]→ MCP Protocol ←[same MCP Servers]→

Implementations:
- 3 MCP Clients (one per AI host)
- 3 MCP Servers (one per service)
Total: 3 + 3 = 6 (vs 3 × 3 = 9 without MCP)

The magic: The MCP Servers for GitHub, PostgreSQL, and Slack work with any AI host that has an MCP Client. They don't need to know whether it's Claude Code, Cursor, or Windsurf.

The 3 roles in MCP

1. MCP Host

The Host is the AI application the user interacts with directly.

Examples of Hosts:
├── Claude Code (Anthropic's CLI)
├── Cursor (IDE with AI)
├── Windsurf (Codeium's IDE)
├── Claude Desktop (desktop app)
└── Zed (editor with MCP support)

Host responsibilities:

• Presents the interface to the user
• Decides when to use MCP servers
• Handles permissions and security
• Can connect to multiple MCP servers simultaneously

2. MCP Client

The Client is the component inside the Host that speaks the MCP protocol.

Claude Code (Host)
└── MCP Client (internal component)
    ├── Connects with GitHub's MCP Server
    ├── Connects with PostgreSQL's MCP Server
    └── Connects with Slack's MCP Server

Client responsibilities:

• Establishes the connection with MCP Servers
• Discovers what each Server can do (capabilities)
• Sends requests and receives responses
• Manages the connection lifecycle

Note: As a developer, you normally don't build the Client — it already ships implemented in the Host (Claude Code, Cursor, etc.). You build Servers.

3. MCP Server

The Server is your code — the program that exposes capabilities to the Host via MCP.

Your MCP Server (example: database server)
├── Resources: data the model can read
│   └── "database://users" → list of users
├── Tools: functions the model can execute
│   └── "create_user(name, email)" → creates a user
└── Prompts: reusable templates
    └── "analyze_schema(table)" → analysis template

Server responsibilities:

• Exposes capabilities (Resources, Tools, Prompts)
• Responds to requests from the Client
• Executes operations (queries, API calls, etc.)
• Handles errors and returns results

This is what you're going to build in this guide.

MCP in action: complete examples

Let's see how a complete flow works with MCP in two different scenarios:

Scenario 1: "How many users does my database have?"

1. User in Claude Code:
   "How many users are there in the database?"

2. Claude Code (Host) processes:
   → Identifies that it has a database MCP Server connected
   → The Server exposes a tool "count_records(table)"
   → Decides to use that tool

3. MCP Client sends request:
   → Tool call: count_records(table="users")
   → Via the standard MCP protocol

4. MCP Server (your code) receives:
   → Executes: SELECT COUNT(*) FROM users
   → Result: 1,247

5. MCP Server responds:
   → { "count": 1247 }
   → Via the standard MCP protocol

6. Claude Code presents to the user:
   "There are 1,247 users in the database."

This entire flow uses the standard MCP protocol. The same MCP Server would work with Cursor, Windsurf, or any other host that supports MCP.

Scenario 2: "Create a ticket with the bug I just found"

This scenario shows a more complex flow where Claude Code uses multiple MCP servers in a single interaction:

1. User in Claude Code:
   "I found a bug in the /api/users endpoint that returns 500
    when the email is null. Create a ticket in Linear and
    notify the team in Slack."

2. Claude Code (Host) processes:
   → Identifies that it has Linear and Slack MCP Servers connected
   → Plans to use both tools sequentially

3. MCP Client sends the first request to the Linear Server:
   → Tool call: create_issue(
       title="Bug: /api/users returns 500 when email is null",
       description="...",
       priority="high",
       labels=["bug", "api"]
     )

4. Linear MCP Server receives and executes:
   → Creates the ticket via the Linear API
   → Returns: { "issue_id": "BUG-234", "url": "..." }

5. MCP Client sends the second request to the Slack Server:
   → Tool call: send_message(
       channel="#engineering",
       text="🐛 New bug reported: BUG-234 - /api/users
             returns 500 when email is null. Priority: High"
     )

6. Slack MCP Server receives and executes:
   → Sends the message via the Slack API
   → Returns: { "sent": true, "channel": "#engineering" }

7. Claude Code presents to the user:
   "Done. I created the ticket BUG-234 in Linear with high priority
    and notified the team in #engineering on Slack."

This demonstrates MCP's composability — multiple servers working together in a single flow, each handling its own domain. Claude Code orchestrates the sequence because it understands the standard protocol of both servers.

Notice something important: at no point did you have to tell Claude Code "use the Linear server and then the Slack server." You only described what you wanted to achieve. Claude Code, knowing the capabilities of each server (thanks to the MCP protocol's discovery), decides which tools to use and in what order. That's the difference between a mechanical integration and an intelligent flow.

What you didn't see but happened

In both scenarios, there are steps that MCP handled automatically behind the scenes:

1. Discovery: When Claude Code started up, it contacted each MCP server and asked it "what can you do?" Each server responded with its list of capabilities (tools, resources, prompts).
2. Selection: When it received your request, Claude Code evaluated which available tools were relevant and chose the correct ones.
3. Serialization: The tool call's arguments were serialized into a standard format (JSON) and sent to the server.
4. Response: The server processed the request and returned results in a standard format.
5. Presentation: Claude Code interpreted the results and presented them in natural language.

All of this happened in milliseconds. You're going to see these steps in detail in module 2.

What makes MCP different from other solutions

MCP vs ChatGPT Plugins

ChatGPT Plugins:
- ❌ Only work with ChatGPT
- ❌ Proprietary to OpenAI
- ❌ No access to the local system
- ❌ Limited to HTTP
- ❌ Discontinued/replaced by GPTs

MCP:
- ✅ Works with any host that implements it
- ✅ Open protocol (anyone can implement it)
- ✅ Access to the local system (stdio transport)
- ✅ Multiple transports (stdio, HTTP/SSE)
- ✅ Actively developed and adopted

MCP vs direct REST API

Direct REST API:
- ✅ Well-established standard
- ❌ Doesn't define capability discovery
- ❌ Doesn't define how AI hosts should interact
- ❌ Each host needs custom logic for each API

MCP:
- ✅ Defines capability discovery
- ✅ Defines the AI host ↔ service interaction
- ✅ One server works with all hosts
- ✅ Can use REST under the hood

MCP vs Function Calling (OpenAI)

Function Calling:
- ✅ Lets the model invoke functions
- ❌ Only defines the model's side
- ❌ Doesn't standardize the server side
- ❌ Proprietary to each vendor

MCP:
- ✅ Standardizes both sides (host + server)
- ✅ Includes Resources and Prompts in addition to Tools
- ✅ Complete lifecycle protocol
- ✅ Open source and vendor-neutral

MCP's design principles

MCP wasn't designed at random. There are clear design principles that explain why the protocol is structured the way it is:

1. Open protocol

MCP is open source. The specification, the SDKs, and the reference servers are publicly available. Anyone can implement a Host, Client, or Server without asking permission or paying licenses.

Why does it matter? Proprietary protocols create lock-in. If ChatGPT's plugins had been open, other hosts could have adopted them and today we'd have a unified standard instead of fragmented ecosystems. MCP avoids that mistake by design: being open, adoption has no legal or commercial friction.

2. Vendor-neutral

It doesn't belong to one company. Although Anthropic created it, the protocol is open and any AI host can adopt it — and they're doing so (Cursor, Windsurf, Zed, Continue.dev, etc.). Anthropic doesn't charge for MCP or have exclusive control over its evolution.

Why does it matter? If MCP were the exclusive property of Anthropic, Cursor and Windsurf wouldn't have adopted it — why strengthen your competitor's ecosystem? By being vendor-neutral, everyone wins: hosts get an ecosystem of servers for free, and servers get reach across all hosts.

3. Composable

A Host can connect to multiple Servers simultaneously. You can have a GitHub Server, a PostgreSQL Server, and a Slack Server, all running at the same time in Claude Code. Each server operates independently.

Why does it matter? Composability enables complex workflows. Scenario 2 above — creating a ticket in Linear and notifying in Slack — is only possible because the servers are independent and composable. You don't need a "super server" that does everything; you combine specialized servers like LEGO pieces.

4. Transport-agnostic

MCP can work over different transport mechanisms:

• stdio: For local servers (the most common with Claude Code). The server runs as a child process and communicates via standard input/output.
• HTTP/SSE: For remote servers. Communication via HTTP with Server-Sent Events for messages from the server to the client.
• Streamable HTTP: For efficient bidirectional communication in scenarios that need streaming.

Why does it matter? Different contexts require different transports. A developer using Claude Code on their laptop wants fast local servers (stdio). A company wants centralized servers accessible from multiple machines (HTTP). MCP supports both without changing the server's logic.

5. Progressive capability

A Server can expose as little or as much as it wants. A minimal Server can have 1 tool. A complex Server can have dozens of resources, tools, and prompts. There are no artificial minimum requirements.

Why does it matter? A low barrier to entry is critical for adoption. If creating an MCP server required implementing 20 minimum capabilities, few would do it. With progressive capability, you can start with a server that only has one tool (query_database) and add more capabilities as you need them. Your first server can be functional in 30 lines of code.

MCP's limitations

MCP is powerful, but it's not a universal solution. It's important to understand what it does not solve so you have the right expectations:

What MCP doesn't solve

1. Authentication with external services

MCP defines how your AI host communicates with your MCP server, but it doesn't define how your MCP server authenticates with the external service (GitHub, Slack, PostgreSQL, etc.). You still need to handle API keys, OAuth tokens, connection strings, etc. inside your server.

MCP defines:    Host ←→ Your MCP Server (standard protocol)
You define:     Your MCP Server ←→ External service (authentication, etc.)

2. The quality of the model's responses

MCP gives the model access to data and tools, but it doesn't guarantee that the model makes the right decisions about when and how to use them. If the model decides not to use an available tool or uses it with incorrect arguments, that's a model issue, not a protocol issue.

3. The performance of the underlying service

If your database takes 30 seconds to respond to a query, the MCP server is going to take at least 30 seconds. MCP doesn't optimize the speed of the underlying service — it's a communication layer, not an accelerator.

4. Automatic end-to-end security

MCP has security mechanisms (the host asks for confirmation for sensitive operations, servers define which directories/resources they can access), but end-to-end security depends on how you implement your server. A poorly written server that exposes DELETE FROM users as a tool without confirmation is an implementation problem, not a protocol one.

5. Offline or complex disconnections

MCP assumes an active connection between host and server. It doesn't have a robust offline-first model, result caching, or automatic reconnection with state. If the connection is lost, the session resets.

What MCP does solve (summary)

For context, let's look at the complete list of what MCP does do well:

✅ Capability discovery (the host knows what the server can do)
✅ Standard interface (one server works with all hosts)
✅ Composability (multiple servers working together)
✅ Shared ecosystem (reusing community servers)
✅ Progressive capability (start simple, grow later)
✅ Transport-agnostic (local via stdio, remote via HTTP)
✅ Open source and vendor-neutral (no lock-in)

Troubleshooting

"Does MCP replace REST APIs?"

No. MCP is a layer on top of APIs. Your MCP Server can internally call REST APIs, connect to databases, read files, or do whatever it needs. MCP standardizes how the AI host discovers and uses your Server's capabilities — it doesn't replace what it does internally. Think of MCP as a "universal adapter" between AI hosts and any service.

"Do I need TypeScript or Python to create MCP Servers?"

The official SDKs are in TypeScript and Python, which are the easiest paths. But MCP is a protocol — any language that can handle JSON and stdio/HTTP can implement a Server. There are community implementations in Go, Rust, Java, C#, and others. The SDKs simply make the process easier, but they're not an absolute requirement.

"What happens if an AI host doesn't support MCP?"

Then it can't connect with MCP Servers. But the trend is clear: more and more hosts are adopting MCP. If your favorite AI tool doesn't support it today, it probably will soon. The major ones (Claude Code, Cursor, Windsurf, Zed, Continue.dev) already support it.

"Does MCP add latency to operations?"

Yes, there's a minimal overhead from the protocol communication (JSON serialization, stdio/HTTP communication). In practice, this overhead is negligible compared to the time of the real operations (database queries, API calls). We're talking about milliseconds of overhead vs seconds of real operation. Only in ultra-low-latency scenarios would it be a relevant factor.

"Can I use MCP without Claude Code?"

Absolutely. MCP works with any host that implements it. You can use MCP servers with Cursor, Windsurf, Zed, Continue.dev, and more. The protocol is independent of the host. In this guide we use Claude Code as the main host because it's the one you have the most experience with, but what you build will work in all of them.

Exercises

Exercise 1: Explain MCP in one sentence (Easy)

Write your own definition of MCP in one sentence, without using technical jargon. Imagine you're explaining it to a product manager.

Exercise 2: Map the USB-C analogy (Easy)

Complete this table by mapping each USB-C concept to its MCP equivalent:

Exercise 3: Identify Host, Client, Server (Medium)

In this scenario, identify what is the Host, what is the Client, and what is the Server:

"A developer uses Cursor to write code. Cursor is connected to a program that can read and search the React documentation. The developer asks 'how do you use useEffect?' and Cursor uses that program to look up the answer in the React docs."

Exercise 4: Design a conceptual MCP Server (Medium)

If you were going to build an MCP Server for your favorite service (Notion, Spotify, your work database), what capabilities would it expose? List at least:

• 2 Resources (data the model can read)
• 2 Tools (functions the model can execute)
• 1 Prompt (reusable template)

Exercise 5: Argue MCP vs custom integrations (Hard)

Your CTO says: "We can build custom integrations directly. Why complicate things with MCP?" Write 3 arguments in favor of MCP over custom integrations.

Exercise 6: Identify limitations (Medium)

Read the "MCP's limitations" section of this capsule. Now, for each limitation, describe how you'd handle it in practice if you were building an MCP server for PostgreSQL.

# Example of how I'd pass credentials to the server
MCP_PG_CONNECTION_STRING=postgresql://user:pass@localhost/mydb

Summary

In this capsule you learned:

• MCP is the USB-C of AI — a standard protocol that reduces M×N integrations to M+N implementations
• 3 roles: Host (AI application), Client (communication component), Server (your code)
• MCP defines: Capability discovery, communication protocol, types of capabilities (Resources, Tools, Prompts), and permissions
• MCP vs alternatives: It's open (vs proprietary plugins), standardizes both sides (vs function calling), and is a layer on top of APIs (vs direct REST)
• 5 principles: Open, vendor-neutral, composable, transport-agnostic, progressive capability
• Limitations: MCP doesn't solve authentication with external services, the underlying service's performance, or automatic end-to-end security
• What you'll build: MCP Servers — the code that exposes capabilities to any AI host

Next capsule: The current MCP ecosystem — who uses MCP today, what servers exist, and how adoption is growing.

Additional resources

1. Model Context Protocol — Specification - Full technical specification
2. MCP Architecture Overview - Official architecture documentation
3. Introducing MCP (Anthropic Blog) - Official announcement with design context
4. MCP GitHub Organization - Official repos: spec, SDKs, reference servers
5. USB-C Specification - The real analogy: how a standard unified hardware
6. Awesome MCP Servers - Community directory of MCP servers