MCP Servers: Doors for Your Agent.
Claude Code is a brilliant operator locked in a room with one computer. It can read files, run commands, and think. It cannot reach into your inbox, your calendar, or your team's chat unless you give it a door. MCP servers are those doors. Install one and your agent gains a new sense, a new capability, a new place it can act.
- A working mental model for what an MCP server is and why it matters to everything your agent does next.
- The connector vocabulary so you can move between Claude Code, Claude Desktop, and Anthropic's docs without getting lost.
- A clear sense of when to reach for an MCP versus when a CLI is the better tool for the job.
Pick your first door, then open it.
Paste this into Claude Code. It reads the official MCP docs so its answers stay accurate, helps you choose which connector to install first based on the tools you actually use, and walks you through the real install command.
How this fits in the OS.
Claude Code installed and a CLAUDE.md so your agent knows what tools to use proactively.
The claude mcp add command, the services you already work in, and the credentials you keep in your secret manager.
An agent that can act in Gmail, Calendar, Notion, Slack, GitHub, and the rest of your stack instead of only the local file system.
The room your agent lives in.
Think of Claude Code as an extremely capable operator working at one desk with one computer. Out of the box it can read and write files on that machine, run commands, think brilliantly, and glance out the window to look something up on the open web. What it cannot do, by default, is walk into the rooms where your real work lives. It cannot open your inbox, check your calendar, post in your team's chat, or read your private Notion. Those rooms are locked, and the keys are yours.
MCP servers are the doors into those rooms.
MCP stands for Model Context Protocol (Claude Desktop calls these connectors). It is a standard way for your agent to talk to external tools and services. Each MCP server you install is a new door your agent can walk through: one for Gmail, one for Calendar, one for Notion, one for Slack. The protocol is the same. The destination on the other side of the door is different.
Without MCP servers, your agent knows what you tell it and can act only on the files on your machine. With MCP servers, it can read and act inside every service you connect: see the email and draft the reply, spot the calendar conflict and move the meeting, open the Notion page and write the update. It is not just more aware. It can reach in and do the work.
Two names for the same thing.
You will see two words for this idea, depending on where you are reading.
- MCP server is the canonical engineering term. This is what the protocol is actually called, what the docs say, and what the install command uses. When you wire up Gmail with
claude mcp add, you are adding an MCP server. - Connector is the friendlier name Anthropic uses inside Claude Desktop. Same idea, softer label. When your less technical teammate says "I added the Gmail connector to Claude," they have installed an MCP server.
The portal uses both. MCP is the precise word. Connector is the word that travels well outside the workshop. Either one is correct.
What an MCP gets you.
An MCP server is a translator that sits between your agent and an external service. Your agent sends a request. The server talks to Gmail or Notion or Slack on your behalf. The response comes back through the same door. Some servers run locally, as a small program on your own machine. Others, including most of the big SaaS connectors like Notion, Slack, and GitHub, are hosted remotely: you connect to them by web address and approve access in your browser the first time. Either way, you do not manage the wiring. You only decide which doors to open.
A few of the doors you will see most often:
- Gmail. Read inbox, search messages, draft replies, send on your behalf when you approve.
- Google Calendar. See your week, create events, find conflicts, move things.
- Notion. Read and write your notes, databases, and wikis.
- Slack. Read messages, post to channels, search conversations.
- GitHub. Read repos, open issues, review pull requests.
- Firecrawl, Brave, or Exa. Deeper web search and full-page scraping, past the quick lookups Claude can already do on its own.
You do not install all of them. You install the doors to the rooms you actually live in. The value comes from your agent being embedded in your real workflow, not from a checklist of every available connector.
MCPs and CLIs are different doors.
The workshop puts a lot of weight on CLIs, and it is worth being clear on how they relate.
An MCP server is a packaged, standardized integration with one service. It is fast to install, it speaks a known protocol, and it is the right tool when a vendor or the community has already done the wiring well. Gmail is a perfect example. You do not want to write a Gmail integration. You want to install one. Two honest catches ride along with that convenience. An MCP connects to one account at a time: run a personal and a work Gmail, and a single Gmail connector sees one of them, not both. And every MCP you turn on loads its full set of tool definitions into your context window at the start of every session, before you type a word. One or two connectors is nothing. A stack of chatty ones quietly spends the context budget your real work needs.
A CLI is a custom command-line tool you (or your agent) wrote to do a specific job, often by stitching together API calls and your own logic. Your agent runs it through the shell, so only the command and its output touch the context window, not a wall of tool definitions waiting in the background. CLIs win when you need control: a workflow no MCP covers, a connector that is too shallow, several accounts on one service (a CLI routes per command, so a single tool can drive all of your Gmail accounts), or a tool your business runs on that no vendor ships. And because you can layer your own skills on top of a CLI, you are not boxed into the operations a provider chose to expose. You build the exact commands your day actually needs.
The contrast in one glance:
| Borrow an MCP | Build a CLI + skills | |
|---|---|---|
| Setup | Toggle on in seconds | About a day to build |
| Accounts | One at a time | Many, routed per command |
| Context cost | Loads all its tool definitions into your context window every session | Just the command and its output |
| Control | The operations the vendor chose to expose | Any operation, shaped by your skills |
That is the primer view. The full seven-dimension breakdown and the build-or-borrow decision tree live on the decision card linked just below.
This is the direction the AI Build Lab team has moved. Tyler increasingly reaches past the vendor MCP, builds his own CLI for a service, and writes skills on top of it, so his agents run nuanced, practical workflows shaped to how he actually operates instead of the generic surface a provider ships. You grow into it across the later stages: when to build a CLI, building your first one, and the four-layer architecture production fleets use.
The rule of thumb most operators land on: borrow an MCP when one exists and fits. Build a CLI when the MCP is missing, shallow, multi-account, or the work is yours alone. Both are doors. They just open differently.
Every door you open is also a door something can walk through. An MCP server with full Gmail access can read every message you have ever received. That is the point, and it is also the risk. There is a second, subtler risk: a server that pulls in outside content, such as web search, an inbox, or an issue tracker, can carry a prompt injection, text written to hijack your agent into doing something you never asked. Install only servers you trust, lean on Anthropic's reviewed connector directory when you can, keep credentials in a secret manager, and keep the autonomy rules in your CLAUDE.md honest about what your agent may do without asking.
What changes once the doors are open.
Picture a normal Monday at 8:58am. You want to know what your day looks like and which meetings you can move.
You open your calendar, paste the week into chat, ask which meetings can move, read the answer, then switch back to the calendar and move them yourself.
You type one line: "What does my day look like, and which meetings can move?" The agent reads the calendar, spots the 2pm conflict, and moves it. You never left the chat.
That one difference, multiplied across every tool you connect, is the whole shift. Three things start happening:
- You stop copy-pasting. You quit shuttling email threads, calendar invites, and Notion pages into chat just to give your agent context. It already has the context, because the door is open.
- Your prompts get shorter and more direct. "Draft a reply to the last email from Sarah at Pinnacle" lands cleanly when the agent can actually go look at the last email from Sarah at Pinnacle.
- You start using your agent in the seams of the day. Five minutes between meetings is enough to triage an inbox, reschedule a conflict, or summarize a long Slack thread. That only works when the doors are already open.
The first MCP feels like a small convenience. The fourth or fifth one is when the room your agent lives in starts to feel like your room.
Straight from the source.
MCP is an open standard and an official Claude feature, so the primary docs go deeper than a primer can. Three worth a bookmark:
- Connect Claude Code to tools via MCP: the canonical reference. The real
claude mcp addsyntax, the three transports (local, HTTP, SSE), the local, project, and user scopes, and how browser sign-in works. Read this before your first real install. - Anthropic connector directory: the reviewed catalog of remote MCP servers you can add by web address. The safest place to find a connector for a tool you already use.
- Model Context Protocol: the open protocol itself, for when you want to understand what is actually moving through the door, or build a server of your own.
Where to go next.
Reading about MCPs is the warmup. Installing one is the work. Three natural next moves: