MCP in plain English — and what to install first
Your AI knows everything about the internet and nothing about your stack. MCP is the boring protocol that fixed that. Here's what it actually is, what it isn't, and the three servers worth installing this afternoon.
Your AI knows everything about the public internet and nothing about your stack.
It can quote you the Stripe API from memory but can't see your Stripe account. It knows the shape of a Postgres connection string but can't reach your database. It has read every line of GitHub's docs but doesn't know which repos you have access to.
For two years, every AI app tried to fix this with its own plugin system. ChatGPT plugins. Custom GPTs. Cursor extensions. Claude tools. Each one a fresh integration to write, a fresh auth flow to set up, a fresh thing to break next quarter.
Then in late 2024 Anthropic shipped MCP — Model Context Protocol — and within a year every major AI tool adopted it. This post is what it actually is, what it isn't, and the three servers worth installing this afternoon.
What MCP actually is
MCP is a wire protocol. It defines how an AI app (the client) talks to an external capability (the server) over JSON-RPC. That's it. That's the spec.
The Anthropic team's own framing — "USB-C for AI" — is the right mental model. Before USB-C, every device shipped its own cable. After USB-C, you carry one cable and plug it into anything. MCP is the same idea, applied to AI integrations.
You write one MCP server for your database. Claude Desktop can use it. Cursor can use it. Claude Code can use it. Zed can use it. Cline can use it. You wrote it once.
The transport is JSON-RPC over stdio or HTTP. Boring on purpose. The boring part is why it spread — there's no clever new format to learn, no proprietary auth dance, no vendor-specific quirks to fight.
What MCP isn't
Most of the confusion online comes from people mistaking MCP for things it isn't.
It's not an AI model. MCP servers don't generate text. They expose tools, data, and prompts the model can use. The model is whatever you're already using — Claude, GPT, Gemini, Llama, doesn't matter.
It's not a plugin marketplace. There are catalogs (ours is at /mcp, Anthropic's, Smithery, mcp.so) but MCP itself is just the protocol. There's no app store gatekeeper, no review process.
It's not an API spec. A REST API defines what endpoints exist. MCP defines how an AI client discovers what a server offers. The model asks the server "what can you do?" and gets a typed list back. That dynamic discovery is what makes it work across tools.
It's not magic. Installing an MCP server doesn't make your AI smarter. It gives the AI a typed function it can choose to call. The quality of the result still depends on the model — and on whether the server's tool descriptions are clear enough for the model to pick the right one.
The three primitives
MCP servers expose three things, in order of how often you'll see them:
Tools. Functions the model can call. read_file, query_postgres, create_issue. The model decides when to use them based on the natural-language description in the tool's metadata. This is 90% of what most servers do.
Resources. Data the model can read on demand. A file. A database row. The content of a Notion page. Different from tools because there's no side effect — the model is fetching, not acting.
Prompts. Reusable templates a server exposes for common workflows. Less common in practice; most teams pass their templates around as text instead.
If you only remember one thing: a tool is a function the model can call, a resource is data the model can read, a prompt is a template a server offers. Servers usually focus on the first.
Why it spread so fast
Before MCP, integrating an AI app with N tools required N×M integrations — every AI app had to write its own connector for every service.
After MCP, it's N+M. Each service writes one MCP server. Each AI app writes one MCP client. Everything composes.
That's not interesting on a slide. It's interesting at 11pm on a Tuesday when you realise you can swap Cursor for Claude Code without rewriting your Linear integration.
What to install first
Three servers will cover 80% of what you'd want an AI assistant to do in your work. Install them in this order.
1. Filesystem. Lets the model read and edit files in folders you specify. Even if you do nothing else, this changes Claude Desktop from a chat to a real assistant. npx -y @modelcontextprotocol/server-filesystem /Users/you/projects — that's it.
2. GitHub. Read issues, summarise PRs, search across all your repos. The official GitHub-maintained server, scoped by your token's permissions. Triage and release-notes work that used to take 20 minutes becomes one prompt.
3. One that matches where your work lives. Postgres if your work is data. Linear if your work is product. Notion if your work is docs. Sentry if your work is debugging. Pick one — don't install all of them at once, the model will choke on tool selection.
Setup for all three is a few lines in claude_desktop_config.json (Claude Desktop), one claude mcp add command (Claude Code), or a settings panel (Cursor, Zed, Windsurf). Full snippets and 30 more servers are at /mcp.
Three gotchas
A few things people learn the hard way.
1. Server quality varies. Good MCP servers look like well-designed APIs — narrow tools, clear descriptions, structured errors. Bad ones expose 80 tools, name them ambiguously, and confuse the model into picking the wrong one. If your AI is suddenly worse after installing a server, the server is probably the problem.
2. The scope of the token is the scope of the damage. An MCP server inherits the permissions of whatever auth you give it. A Postgres server with read-write production credentials can drop a table on the wrong prompt. Use read-only tokens, scoped credentials, sandboxes. The protocol won't save you from yourself.
3. "MCP" in marketing doesn't mean "official." Anyone can write a server and call it the "Acme MCP server." Some are excellent. Some are abandoned six-week-old experiments. Check the maker and the last-updated date before installing.
What's coming
The next two years of MCP are about coverage, not protocol changes. Every SaaS will ship an MCP server. Every AI client will speak it natively. The friction of "make AI work with X" will go from a project to a config snippet.
Two things to watch:
- Remote MCP servers (Stripe, Cloudflare, Vercel) skip the local process entirely. The AI client connects over HTTP. Easier setup, but you trust the server with whatever auth you give it.
- MCP-aware UIs — clients that surface which server provided which result, so you can see when a tool call returned suspect data. Cursor and Claude Code have early versions; expect this to become standard.
The take
MCP isn't an interesting product. It's an interesting equilibrium. Nobody had to win the plugin war because everyone could just adopt the same wire format and move on.
The result, almost by accident: your AI can finally see your stack. Not because the model got smarter — because the model got connected.
If you've been hearing about MCP and wondering whether to pay attention: install filesystem and one service-specific server this afternoon. Use it for a week. The "before" and "after" is the kind of difference you don't undo.
The full catalog of 30 hand-picked MCP servers — what they do, how to install — is at /mcp. Want the longer technical definition? /glossary/mcp.
Get the next post when it ships
One email on Sunday with the new post and a short list of what shipped that week — new guides, tool updates, and a couple of links worth reading.