Protocols
As soon as an AI app needs files, GitHub, a database, or anything beyond the prompt, it needs a way to connect. MCP is the cleanest current example, so it is the one worth learning first.
The short version
If you have ever wanted one assistant to use the same filesystem or GitHub tool as another, this is the problem MCP is trying to solve. It gives hosts and tool servers a shared shape instead of making everyone rebuild the same custom integration again.
Useful, yes, but keep it in proportion. MCP is wiring. It can make a host more connected, but not automatically smarter, safer, or more trustworthy.
Common shape
Before shared protocols, every AI app wound up with its own pile of one-off integrations: one way to talk to GitHub, another way to talk to a database, another way to read local files, and so on.
A protocol gives tool builders a shared shape. If a host supports that protocol, it can connect to many compatible adapters. If an adapter speaks that protocol, many hosts can use it.
Model Context Protocol is like USB-C for AI context and tools: not the device itself, but a standard connection that lets different devices plug into different hosts.
More technically, MCP is an API contract for tools: the host agrees to discover and call tools in a specific shape, and any server that speaks that shape can plug in.
By 2026, MCP has become the dominant standard shape for tool integrations across coding assistants and developer-facing hosts.
In practice
A protocol helps hosts and capabilities meet cleanly. It does not decide goals, approvals, or the rest of the agent loop.
ELI5: A travel plug that lets the same device fit a different wall socket.
What it actually is: A standardized interface that exposes tools, resources, or prompts so more than one host can discover and call them.
Try it: Build the shape in lab 03.
Real tools: MCP servers, OpenAPI-described services (web APIs with machine-readable docs), LSP servers (editor code-intelligence services).
ELI5: Sometimes the appliance ships with ports built in, so you do not need an external adapter.
What it actually is: Many hosts now ship built-in file, shell, Git, or web tools that overlap with what a protocol adapter could expose.
Try it: Compare the protocol layer in lab 03 with the host layer in lab 09.
Real tools: Claude Code-style built-ins, GitHub Copilot CLI tool surfaces, Goose + MCP, Gemini CLI + MCP.
Connection shape
The application that coordinates the experience: a CLI assistant, IDE, desktop chat app, or internal tool.
Owns UX, approvals, conversation, and model access.
The host-side connection object. Users usually do not interact with it directly.
Maintains one dedicated connection to one server.
A program that exposes capabilities and context to the host in a standardized way.
Can run locally over stdio or remotely over HTTP.
MCP primitives
Plain English: Actions the model can ask to run.
Technical: Model-controlled executable functions with names, descriptions, input schemas, and structured results.
Example: create_issue, query_database, get_weather.
Plain English: Data the host can load as context.
Technical: URI-addressed content such as files, records, schemas, logs, or API responses.
Example: file:///project/README.md, database schema, Sentry event.
Plain English: Reusable instruction templates.
Technical: Server-provided prompt definitions that can take arguments and return structured messages.
Example: "review this code", "summarize this incident".
MCP has continued evolving since its initial release. Current versions formalize the server-side primitives (tools, resources, prompts) and client-side capabilities (sampling, roots, elicitation), and add Streamable HTTP alongside stdio as a supported transport. Check the official spec for the current feature set. The protocol moves fast.
Transport
The host starts a local process and communicates over standard input and output. This is common for local filesystem tools, local scripts, and developer-machine integrations.
Good for local tools and simple installation.
The host talks to a remote server over HTTP, often with bearer tokens, API keys, OAuth, or other service authentication.
Good for hosted services and shared enterprise integrations.
Auth note: protocol auth and secret safety are different problems. See API key security.
How it got this shape
Before MCP, every serious host started accumulating its own adapter zoo. Reading GitHub, browsing local files, hitting an API, talking to a database: each connection usually meant custom code on both sides.
MCP showed up in late 2024 right when that duplication was getting hard to ignore. Tool-calling already existed. Coding assistants were already popular. What was missing was a shared interface people could actually reuse.
That is why the USB-C analogy keeps surviving. It is not perfect, but it is fair. USB-C does not make the device smarter; it just gives everyone a connector they can agree on. MCP plays the same role for hosts and tool servers.
The scale changed fast. By late 2025, public MCP listings were already in the thousands, depending on how you count servers, wrappers, and mirrors. If you want to see what already exists before building your own, mcpservers.org is one community registry worth checking, but it is not the only one.
How it relates to skills
It is easy to read about skills and MCP and feel like they overlap. They can, but they answer different questions. MCP is about how a tool gets exposed at all. A skill is about knowing when and how to use the tools you already have.
Reach for a protocol when the capability is not exposed any other way, when you want the same tool to work across more than one host, or when the action is expensive or risky enough that you want a typed contract around it.
Good signs: structured inputs and outputs, stateful resources, side effects where a wrong call costs something.
Reach for a skill when the tool calls already exist and the real gap is judgment: when to start, what order to follow, how to check the result. There is no server to run and no auth to configure.
Good signs: lower overhead, simpler to deploy, the host already has the tools it needs.
The deeper difference is how much is pinned down. MCP gives you two deterministic anchors: the execution is just a function, and the schema fixes the shape of inputs, outputs, and errors. A skill is the opposite kind of thing. It is stochastic guidance that a model still has to reason about, even though it can drive perfectly deterministic machinery underneath.
Worth being precise here: a schema catches shape errors, not intent errors. MCP can stop you from sending the wrong type, but it cannot stop you from sending a value that is the right type and still wrong for the job. That part stays on the reasoning side, which is where skills live.
Roughly, MCP is winning the standardization argument while skills are winning on adoption. They may settle into complementary layers: the protocol as plumbing, the skill as the guidance sitting on top of it. See skills, hooks, and wrappers for the layer skills live in.
Boundary check
| Question | Protocol answers? | What usually answers it |
|---|---|---|
| How does the host discover tools? | Yes | MCP tools/list, resources/list, prompts/list. |
| Which tool should the model use? | Partly | The model, host, agent runtime, system prompt, and tool descriptions. |
| Should the user approve the action? | No | The host app, policy layer, hooks, or enterprise controls. |
| How should a multi-step task be planned? | No | The agent runtime or orchestration framework. |
| Where does long-term memory live? | Maybe | A memory service could be exposed through a protocol, but memory policy is broader than the protocol. |
The host starts the adapter. A desktop or CLI assistant launches a local filesystem MCP server over stdio.
The host discovers what exists. It asks for resources and tools, then learns that project files can be read.
The model asks for context. The host reads a file resource or calls a tool, then feeds the result back into the conversation.
Ready to build
Reading about protocol adapters only gets you so far. Lab 03 has you build a tiny one so you can feel the boundary for yourself: list tools, accept typed calls, and hand structured results back to a host.
If you would rather skip straight to something real and usable, go to Lab 03b: real MCP quickstart →
If Lab 03b still feels like more setup than you want, fastmcp is worth knowing. It is an active Python library that uses decorators instead of a lot of protocol boilerplate. It is not the default everywhere yet, but it is probably the ergonomic builder choice right now.
And if MCP still feels suspiciously similar to a wrapper, that is a good instinct. Start with lab 02, then come back here.