What Is the Model Context Protocol?
MCP in One Sentence
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems. Using MCP, an AI application like Claude can connect to data sources (local files, databases), tools (search engines, calculators, APIs), and workflows (specialized prompts) — so it can access the information it needs and take real actions on your behalf, instead of being limited to whatever it learned during training.
The USB-C analogy
Think of MCP like a USB-C port for AI applications. Just as USB-C gives you one standardized way to connect many devices, MCP gives you one standardized way to connect an AI application to many external systems. Build a server once, and any MCP-compatible client can use it — no custom adapter per pairing.
Two properties make that analogy hold. First, MCP is built on a well-known foundation — JSON-RPC 2.0 — so the message format is predictable and language-independent. Second, it is an open protocol, not an Anthropic-only feature: Claude, ChatGPT, VS Code, Cursor, Windsurf, and many other applications speak it. That shared standard is the whole point — write an integration once and it works across every compatible client.
The Problem MCP Solves
On its own, a large language model is a closed box: it can only read the text you put in the prompt and write text back out. It cannot open your files, query your database, hit a live API, or click a button. To make an AI application genuinely useful, you have to connect the model to the outside world — and historically that meant writing custom integration code for every system.
Say you want Claude to answer questions about your GitHub data — "What open pull requests are there across all my repositories?" GitHub has enormous surface area: repos, pull requests, issues, projects, actions, and far more. Without MCP, you would hand-author a tool schema and an implementation function for every operation you wanted to support, then test and maintain all of it yourself. Now multiply that by every service you integrate (Slack, Jira, your database, your calendar) and by every AI app your team builds. That is the M×N integration problem: M applications each needing bespoke code for N systems.
Without MCP, every app writes custom code for every service (M×N connections). With MCP, each app and each service implements the standard once — collapsing to M+N.
MCP turns that M×N problem into a simpler M+N one. Each AI application implements MCP once (the client side). Each external system is exposed once through an MCP server. Any client can then talk to any server through the same standardized protocol — no bespoke glue code per pairing, and no re-implementing GitHub's API for the hundredth time.
How MCP Shifts the Burden
The core idea is to move tool definition and execution off your application and onto a dedicated MCP server. Instead of you authoring every GitHub tool, an MCP server for GitHub wraps that functionality and exposes it as a standardized set of tools. Your application just connects to the server and asks what it offers.
Crucially, anyone can author an MCP server, and service providers increasingly ship official ones. There are maintained servers for GitHub, Slack, Sentry, Postgres, the local filesystem, and hundreds more. When you adopt one, you inherit tools that are already implemented, tested, and kept up to date by people who know that service best — instead of owning that maintenance burden yourself.
MCP vs. tool use — a common confusion
MCP and Claude's tool use are complementary, not the same thing. Tool use is HOW Claude calls a tool — the request/response mechanics in the model API. MCP is about WHO provides the tools: instead of you authoring every tool schema and function by hand, an MCP server provides them already implemented and standardized. Put simply: tool use is the act of calling a tool; MCP is the supply chain that delivers the tools to be called.
| Aspect | Calling an API directly | Using an MCP server |
|---|---|---|
| Tool schemas | You write and maintain every one | Provided by the server, ready to use |
| Implementation | You code each function against the API | Already implemented inside the server |
| Discovery | Hard-coded into your app | Queried at runtime via tools/list |
| Reuse across apps | Re-written per application | One server works for every MCP client |
| Maintenance | Yours — breaks when the API changes | The server author's responsibility |
| Updates / new tools | You add them manually | Appear automatically when the server adds them |
MCP doesn't replace APIs — it standardizes and shares the integration layer on top of them.
What MCP Lets You Build
Once an AI application can reach external systems through a common protocol, the range of what it can do expands dramatically. A few real examples from the MCP ecosystem:
- •A personal agent that reads your Google Calendar and Notion to plan your week and draft updates.
- •Claude Code generating a complete web app directly from a Figma design file.
- •An enterprise chatbot connected to multiple databases so non-technical staff can analyze data through chat.
- •An AI model creating a 3D design in Blender and sending it to a 3D printer — entirely through MCP tools.
Concretely, a tiny MCP server is just a few lines of Python. This is the entire definition of a working server that exposes one tool — note there is no JSON schema to hand-write; the decorator and type hints generate it for you:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Demo")
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers together."""
return a + b
if __name__ == "__main__":
mcp.run(transport="stdio")Where this course goes next
You now have the mental model: MCP is a standard connection layer that supplies tools, data, and prompts to AI apps. Next we'll meet the three participants — host, client, and server — and trace exactly what travels between them on every request.
Key Takeaways
- ✓MCP is an open standard for connecting AI applications to external data sources, tools, and workflows — built on JSON-RPC 2.0 and supported across many clients (Claude, ChatGPT, VS Code, Cursor).
- ✓The mental model is a 'USB-C port for AI': build a server once and any MCP-compatible client can use it.
- ✓On its own an LLM can only read and write text; MCP is how it reaches files, databases, APIs, and actions in the outside world.
- ✓MCP solves the M×N integration problem — M apps × N systems of custom code — by standardizing it into an M+N model.
- ✓It shifts tool definition and execution onto dedicated MCP servers, so you inherit ready-made, maintained integrations instead of writing them.
- ✓MCP is complementary to tool use: tool use is how Claude calls a tool; MCP is how the tools get supplied without custom integration code.
- ✓MCP standardizes the integration layer on top of APIs — it does not replace the underlying APIs themselves.
Check Your Understanding
Test what you learned in this lesson.
Q1.What problem is MCP primarily designed to solve?
Q2.Which statement best captures the relationship between MCP and Claude's tool use?
Q3.How does using an MCP server differ from calling an external API directly in your own code?
Q4.The 'USB-C port for AI applications' analogy is used to convey which property of MCP?
Practice This Lesson