An MCP server is a small program that lets your AI app use something outside the chat: a database, a docs site, a project tracker. By the end you'll know how to add one in Claude Code, which scope to pick, and a four-question check to run before you install anything.
An MCP server is a menu your AI app can order from
MCP stands for Model Context Protocol. It's an open standard that Anthropic introduced in November 2024 for how AI agents connect to outside tools, data and services. The common comparison is USB-C for AI: one standard plug, so an AI app doesn't need a custom link for every tool.
There are two sides:
- Client: the AI app you talk to, like a coding agent or a chat app.
- Server: the small program that offers things the client can use.
A server can offer three kinds of things, according to JupiterOne's glossary: tools (functions, API calls, scripts), resources (files, documents, media) and prompts (saved templates).
The flow is short. The client asks "what do you offer?" The server lists its tools with descriptions. The client picks one and sends a structured request, and the server runs it and sends back the result, as the architecture docs describe.
MCP is a standard, not a product. You don't buy it. Servers are separate programs, and many of them are small.
It's not a replacement for an API, it sits on top of one
An API is built for software to talk to software, and someone has to read the docs and write code for each endpoint. An MCP server can sit in front of an API, a database or local files and make selected capabilities available to AI apps, as ClickUp's comparison puts it. The AI app asks what the server can do and uses the answer, with no custom code for that tool, per Bannerbear.
Do you need to code? Not to use a server someone else built. You add it by configuration. You write code only if you build your own, and my rule is simple: build your own only when no server exists for the thing you need.
Here's the math that makes the standard worth caring about. Example: say you use 3 AI apps and 5 tools. Without a shared standard that's 3 x 5 = 15 custom links. With one, it's closer to 3 + 5 = 8 connections.
Local servers run code on your machine, remote ones hold your logins
This is the part most explainers skip. Pick the risk you're taking before you pick the server.
| Local server | Remote server | |
|---|---|---|
| Where it runs | On your machine, next to your AI app | On someone else's computer |
| Main risk | It's code from the internet running with your machine's access | Your data and login tokens pass through it |
| What to check | Who wrote it, and whether you can read the source | Who runs it, and what login it asks for |
Installing a local server means running code on your own machine, often from an independent developer with no shared security standard. Remote doesn't mean safe. Wiz's MCP security briefing warns that a remote server can still lead to stolen credentials or access to other tools your AI app can use.
Turn off auto-run for any tool that can write, send or delete
Many AI apps let tools run without asking. That's convenient, and it's the setting I'd turn off first. Auto-run trusts whatever the server sends back and widens the damage if a server is bad or tampered with.
The rule: read-only first. Let a server look before it can touch. If it asks for write access (delete, send, pay), add that only after you've watched it work on test data.
Where you can set permissions per tool, do it. Stainless's permissions docs show the idea: allow one action, like reading logs, without allowing another, like deleting. Example: let a deploy server show status and logs, but not delete an environment.
Pick the narrowest scope in Claude Code
Claude Code supports MCP servers at three scopes, and claude mcp add uses the narrowest one by default, per Scrimba's guide.
| Scope | Who gets it | Where it's stored |
|---|---|---|
| Local (default) | Just you, in the current project | ~/.claude.json, keyed by project path |
| Project | Anyone who opens the repo | .mcp.json in the project root |
| User | You, in every project | ~/.claude.json, global section |
The storage locations come from MCPBundles' reference. You can also write .mcp.json by hand under an mcpServers section.
When to use which:
- First time trying a server: local. A bad pick stays in one project.
- Something you use daily and it only reads: user, after you've used it for a while.
- The whole repo needs it: project. And read that
.mcp.jsonlike code, because a repo you clone can bring a server with it.
One habit I'd keep: if you open a repo you didn't write and it has a .mcp.json, read it before you approve anything on the list. Keep logins and tokens out of any file you share or commit.
For the safe base setup this sits on, see Claude Code for Non-Developers: A Practical Setup That Stays Safe.
The four-question check you run before you add any server
This is my suggested routine, not a standard. It takes about 10 minutes per server, which is also my own budget, not a measured number.
- Who made it? Can you find the source code and the author?
- What can it do? List every tool it exposes. Mark each as read, write or delete.
- What does it log in with? Does it need a token, and what can that token do?
- Can I test it safely? Use a throwaway account, test data or a read-only login first.
Then do the blast radius check: count the write and delete tools, and say what the worst single wrong call would change. If you can't say, don't add it. If you can't explain in one sentence what the server does, don't install it either.
A six-step routine that fits in one evening
- Pick one job you do by hand that touches something outside your code folder, like looking up docs or reading a tracker.
- Find an existing server for that tool and run the four-question check.
- Add it with
claude mcp add. It lands at local scope. - Test it on throwaway data or a read-only account.
- Look at the tools it exposes and turn off auto-approval for any that write or delete.
- After a week, decide: keep it local, move it to user scope, or put it in the project's
.mcp.json.
Check the exact command flags against the official quickstart before you run them, since they change.
Keep a scope table or you'll lose track
For each server, write four things in a notes file: its name, its scope, what it can read, what it can write. If a user-scope server can write, ask why it has to be active in every project.
The budget is small. Example: say you have 6 servers. At 10 minutes each that's 60 minutes of review, once. Write the answers down and re-check only when a server updates.
Three mistakes cost the most:
- Everything at user scope on day one. A server you only meant to try is now active in projects with private code.
- Installing the first search hit. You're trusting unknown code.
- Skipping the test. One wrong tool call changes real data, and you find out after.
Do this in the next ten minutes
Open a throwaway project. Write down one manual job an outside tool could do for you. Then run the four-question check on one server for it, and stop there. Adding it can wait until tomorrow.
If you want a second pair of eyes on a task you keep doing by hand, Email Me with the job. Running several small apps alone is mostly about not letting any one tool break the rest, which is the idea behind how I run a portfolio of small apps with a team of AI agents.