MCP: Giving AI Real Tools
If an API is how software talks to software, MCP is how AI talks to everything. This lesson builds it from the ground up — the problem it solves, how it works, the three things a server can offer, and exactly what happens when an agent uses one.
Ask Claude what's on your calendar tomorrow and it cannot answer. It has never seen your calendar, and it has no way to reach it. This lesson is about how that gap got closed — for every model and every tool at once.
By the end of this lesson
You'll be able to explain why MCP exists, name its three moving parts, trace a real request through it, set one up yourself, and avoid the two mistakes nearly everyone makes first. About a ten-minute read.
A language model, on its own, can only read and write text. It can reason about your calendar in the abstract, but it cannot open it, because the model is a fixed thing that finished training months ago and lives nowhere near your data. To make it useful, you have to connect it to the real world — your files, your database, an API, your calendar. The question is how.
Why a standard had to exist
A year ago, you connected them by hand. You wrote a custom integration — code that glued one specific model to one specific calendar. It worked, until a new model shipped and you wrote it again, or the calendar changed its API and you wrote it a third time. Now multiply that across a company. If six AI applications each want to reach six data sources, that isn't twelve integrations to build and maintain. It's six times six — thirty-six — each one a small, brittle piece of bespoke code.
The Model Context Protocol (MCP) is the fix. Anthropic released it as an open standard in November 2024: one shared language that any model and any tool can speak. Put it in the middle, and the same six-by-six reach costs six plus six — twelve. You write each connection once, against the protocol, and every model that speaks MCP can use it. That collapse, from N times M down to N plus M, is the entire reason it exists.
The three parts, and what each one does
Every MCP setup has the same three roles. Learn these three words and the rest of the protocol falls into place.
So when you connect Claude Desktop (the host) to a calendar, you're really pointing its client at a calendar server. Hold those three; the next section walks a real question through all of them.
One request, traced end to end
Here's exactly what happens between your question and the answer. Follow “what's on my calendar tomorrow?” through four steps.
Discovery. The moment the host starts, its client asks the server one thing: what can you do? The server replies with a list of its tools — each with a name, a plain-English description, and the exact shape of the arguments it expects. The model now knows a list_events tool exists. Nobody hard-coded that; it was discovered.
Decision. You ask your question. The model reads the tool descriptions, decides list_events is right, and produces a tool call — not a sentence for you, a structured payload for the server:
Execution. The server receives that payload and does the real work — it queries your actual calendar for July 1st and hands back the events as data. The model never touched your calendar; the server did, on its behalf.
Answer. The events come back to the model, which turns the raw data into a sentence: “You have two meetings tomorrow — a 10am standup and lunch at 1.” You read it, and never saw the wiring underneath.
That loop — discover, decide, execute, answer — is MCP in one breath. The model brings the reasoning; the server brings the reach.
Three things a server can offer (and who chooses each)
A server doesn't only expose tools. It offers three kinds of thing, and the way to keep them straight is to ask who decides to use it.
Tools — actions the model chooses to call. list_events, send_email. They do something, and the model decides when.
Resources — read-only data the application pulls in as context: a file, a record, the page you have open. They show something; nobody has to decide to fetch them.
Prompts — reusable templates the user invokes on purpose, like a saved “summarize this pull request” command. They guide a task you start deliberately.
A short way to remember it: tools do, resources show, prompts guide — chosen by the model, the app, and you, in that order.
Setting one up yourself
You almost never write a server — you install one that exists. Adding the official filesystem server to Claude Desktop, so the model can read a folder of your notes, is a few lines in a settings file. Open claude_desktop_config.json and add:
Reading it back: mcpServers is the list of servers to start; filesystem is your name for this one; command and args tell the host how to launch it — run it with npx and grant it the one folder /Users/me/notes. Restart Claude, and the discovery step from earlier happens automatically. Ask it to summarize a note and watch it reach into the folder. No glue, no rebuild — configuration, not code.
The two mistakes everyone makes first
The first is reaching for a tool when you wanted a resource. If the model never needs to decide to fetch something — it should just always have it, like the file you're working on — make it a resource. Forcing it through a tool call adds a decision the model can get wrong, for no reason.
The second is handing a server more reach than the job needs. Every tool you expose is a capability you've granted, and “send email” is also “send the wrong email to everyone.” Scope each server tightly — notice the config above gave the filesystem server one folder, not your whole disk. Give the least access that does the work, and nothing more.
The model brings the reasoning. The server brings the reach. MCP is the contract between them.
Try this next
Add the filesystem server above to a folder of your own notes and ask Claude a question about them. Then browse the official reference servers and the community's awesome-mcp-servers list — you'll find servers for GitHub, Postgres, Slack, and hundreds more. Seeing the range is the fastest way to understand what “give the model a tool” really means. The next lesson tours that ecosystem properly.
Sources — Anthropic, Introducing the Model Context Protocol (Nov 2024); Model Context Protocol docs, Architecture and example servers.
0
Tap to appreciate
Was this chapter helpful?