7.6
Connectors And MCP
Why this exists
You've been using connectors since 1.11 without needing to know what was underneath. Three words come up constantly around them — CLI, API, MCP — and they get used interchangeably by people who'd struggle to define them.
This is the lesson where they stop being noise. It's also the one that turns "API" from a word you repeat into a thing you understand.
The idea
All three are ways for Claude to reach something that isn't Claude. They differ in who wrote the connection.
| What it is | Who built it | |
|---|---|---|
| CLI | A program on your machine it runs directly | Whoever made the tool |
| API | A service over the network it calls | Whoever runs the service |
| MCP | A standard wrapper so any tool plugs into any AI | Whoever wrote the wrapper |
CLI — command line interface. A program already installed that Claude runs the way you would. Cheapest and most direct: no keys to manage, no network, and it's already authenticated because you're logged in. If a CLI exists for what you need, use it.
API — application programming interface. A service somewhere else that Claude sends a request to and gets a response from. This is the word you already knew — a way for one program to ask another program for something over the network. Needs a key, has usage limits, and returns whatever it returns whether or not that's what you wanted.
MCP — model context protocol. A standard shape for those connections, so a tool that speaks MCP works with any AI that speaks MCP, without anyone writing glue for each pairing.
The useful way to think about MCP: it's a wrapper that decides what gets exposed. A raw API gives you everything it's got, in its own format, in whatever volume it feels like. An MCP server sits in front of it and offers a curated set of operations with sensible outputs.
That's not just tidiness. It's a token and safety decision. A raw API response can be enormous and mostly irrelevant, and every bit of it lands in the context window you learned to protect in 2.2. And it's the difference between "Claude can do the four things this wrapper allows" and "Claude can do anything this service permits."
Practically: for the next while you'll use connectors that already exist. Someone wrote the MCP server; you switch it on. The thing to carry from this lesson is what you're switching on — because a connector is access, and the principle of minimal access applies exactly as it did with permission modes in 1.7. Grant what the job needs. Not everything you own.
Do
- Ask Claude: "Explain the difference between a CLI, an API and an MCP server, using examples from what I've got connected."
- Read the answer. Then explain it back in your own words in
connections.md. If you can't, ask again on the part that didn't land. - Use a CLI. Something already installed — git counts. Notice it needed no key.
- Connect one thing you don't currently have connected and that would genuinely be useful.
- During setup, look at what access you're granting. Grant the minimum. Write down what you granted and what you declined.
- Use it for something real.
- Ask Claude to show you what the raw API response would have looked like for the same request. Compare the sizes.
- Finish
connections.mdwith: the three definitions in your words · what you connected · what access you gave it · why the wrapper version is smaller.
Step 2 is the test. This lesson is worthless if you can only repeat the words back.
Done when
Never do
Never grant a connector more access than the job needs. Same rule as permission modes. The convenience of full access is small and the blast radius isn't.
Never connect something you can't explain the purpose of. Every connection is a route into your systems, and one you don't understand is one you can't reason about when something goes wrong.