Why start with a map
Most content about AI agents starts with code. The result: you copy a configuration, it more or less works, and at the first problem you are lost — because you never understood who does what.
This learning path takes the opposite route. Before creating your first skill (step 3) or your first MCP server (step 7), we install the mental model. It is a ten-minute investment that makes the next eight steps obvious — and spares you the most expensive architecture mistakes, the ones you discover in production.
Three actors, three roles. Look at the map above: it will follow you through the entire path.
The model: the brain that orchestrates
At the center sits the language model — Claude, in our case. It is the only actor that decides. Two fundamental points, frequently misunderstood:
The model is confined to its context window. It only "knows" what is inside the current conversation: your messages, the system instructions, and whatever gets injected into it. It has no native access to your files, your database or your calendar. Anything outside the context does not exist for it.
The model is the single point of decision. It chooses to load a skill, it chooses to call an MCP tool, it interprets the results. Skills and MCP servers are passive peripherals plugged into that brain: they never talk to each other directly, and they never trigger anything on their own.
This second point is the source of the most common misconception: no, an MCP server cannot "call a skill". The arrow always starts from the model.
The skill: the expertise manual
A skill is a folder of instructions — concretely, a SKILL.md file, sometimes accompanied by supporting scripts — that the model loads on demand when the task calls for it.
What a skill transfers is know-how:
- "Here is how to produce a professional Word document, done properly"
- "Here is our in-house meeting summary format, the mandatory sections, the expected tone"
- "Here is the deployment procedure, in this order, with these checks"
Two properties give the mechanism its full value:
On-demand loading. The skill does not permanently occupy the context window. Only its description (a few lines) is always visible; the full content is loaded only if the model judges the skill relevant to the task at hand. You can therefore maintain a library of dozens of skills without saturating the context.
The description is the trigger. It — and it alone — lets the model know when to load the skill. An excellent skill with a vague description will never be loaded: in practice, it does not exist. We dedicate a full section to this at step 3, because it is the number-one failure point of skills in the enterprise.
MCP: the hands
MCP — Model Context Protocol — is a standard protocol for plugging the model into external systems. An MCP server is a program (local or remote) that exposes tools: functions the model can call.
What MCP provides is access:
- read and write a PostgreSQL database
- check a calendar, send an email
- query the GitHub API, drive a browser
- read files on a server
The flow of a call is always the same: the model decides to call a tool → the MCP server executes → the result comes back into the context window → the model continues with that new information. The server itself is deliberately dumb: it receives a call, executes, responds. It does not even know skills exist.
The analogy that made the protocol famous: MCP is the USB-C of AI. A standard socket, defined once, into which any tool can plug — instead of building one bespoke integration per model and per service.
One vocabulary point before going further: MCP is the name of the protocol — the standardized grammar of exchange — and what you actually plug in are MCP servers that implement it. Everyday usage says "an MCP" to mean the server; we will sometimes do the same, now that the nuance is set: the hands are the server — the standard socket that lets you plug them in is the protocol.
The three together: the full loop
Let's set the three actors in motion on a real case — the one that will serve as the connecting thread of the entire path: the automated production of a meeting summary.
- You ask: "write up this morning's meeting summary and send it to the team"
- The model loads the skill
house-meeting-summary: it reads the expected format, the mandatory sections, the tone, the distribution rules - The model calls an MCP tool
get_meeting_notesto retrieve the raw notes from your note-taking tool - The model produces the summary by applying the skill's rules to the data returned by the MCP server
- The model calls a second MCP tool
send_summaryfor distribution
The skill provided the how (expertise), the MCP server provided the what (data) and the doing (action). The model orchestrated everything. Neither peripheral made a single decision.
At step 3, we will write that skill. At step 7, we will code that MCP server. By the end of the path, you will have built this full loop with your own hands.
Skills, MCP, RAG, fine-tuning: who does what
The fourth classic source of confusion: situating skills and MCP relative to the two other model "augmentation" techniques, RAG and fine-tuning.
The good news: these four techniques combine. A single assistant can follow a skill (procedure), call MCP tools (access), and rely on RAG (knowledge) — with fine-tuning remaining, in the vast majority of enterprise cases, the last option to consider, not the first. We detailed this decision tree in our RAG in production guide.
📚Going deeper
For the geeks: context window economics. Why does on-demand skill loading matter so much? Because the context window is a finite, billed resource. A permanent instruction in the system prompt = a token cost paid on every request, relevant or not. A skill = a few always-visible description lines (negligible), full content loaded only when needed. On a team assistant handling hundreds of requests per day with 20 documented procedures, the difference between "everything in the system prompt" and "everything as skills" adds up fast: it is the same optimization reasoning we detail in our LLM cost guide. Architecture corollary: a skill must be self-contained and focused — if it needs another skill to work, the decomposition is wrong.
📚Going deeper
For the geeks: where each actor "runs". The model runs at the provider (or locally for open-weight models — see our comparator). The skill "runs" nowhere: it is text loaded into the context; only its optional supporting scripts execute, inside the client's execution environment. The MCP server, however, is a real process: either local (launched on your machine, stdio transport) or remote (an HTTP service). This local/remote distinction has major implications for networking, authentication and attack surface — we will cover them in depth at steps 6 and 8. For now, remember: skill = data, MCP = program. You do not audit data the way you audit a program.
📍 Skills & MCP path — step 1/9
You have just laid down the map. The road ahead:
- 🗺️ The map before the territory ← you are here
- 🔬 Anatomy of a skill
- 🛠️ Create your first skill
- 🏛️ Skills in the enterprise: governance
- 🔌 MCP: the protocol explained
- ⚡ Use an existing MCP server
- ⚙️ Build your minimal MCP server
- 🛡️ Secure your MCP servers
- 📡 The ecosystem: where to find, where it moves
Next step → Anatomy of a skill: we dissect a real SKILL.md file line by line, and you will understand why 20 well-structured lines of text can sometimes be worth a three-week development effort.
To go further right now: our AI agent security decision sheet — "your new employees have no badge" — and the 40 Claude & MCP tools sheet.