You set up a Claude MCP server in Claude Code with the claude mcp add command, either as an HTTP connection to a remote service or as a locally started command. After that, /mcp shows you the status of the connection, and claude mcp list gives you every configured server at a glance. In Claude Desktop, the same idea runs through its own configuration file, more on that below.
MCP stands for Model Context Protocol, an open standard that lets Claude reach tools outside the model itself: an inbox, an ad account, bookkeeping software, an internal database. Without MCP, Claude can only work with what you paste into the chat. With the right server, Claude can check what's actually going on in a connected system, and, if you allow it, change something there too.
I run my business with my own AI workforce on Claude, and each of them only has the MCP connections their job actually needs. Everything else in my Claude setup is on the Claude overview page. My rule for that is always the same: a server gets exactly the rights a role needs for its work, and not one right more.
What an MCP server is, and why a workforce needs one
An MCP server is a bridge between Claude and a specific system. The server tells Claude which tools it offers, say "read inbox" or "create a booking entry," and Claude decides during a conversation when it needs one of those tools. From Claude's side, that's no different from calling a web search or reading a file: it calls a tool with a request and gets a response back.
For an AI workforce like mine, that's the real difference between an assistant that only suggests text and an employee who actually works inside a system. Without MCP, Sonja, my assistant for email, could at best hand you a draft reply to copy. With an inbox connection, she sees the real inbox, knows the thread history, and can drop a draft exactly where it belongs.
Claude Desktop or Claude Code: two paths, one concept
You set up MCP servers in two different places, depending on where you work. In Claude Desktop, you add a server to its own configuration file, which the app reads on startup. In Claude Code, the terminal tool, you instead use the claude mcp add command, which writes the connection directly into your project or your user profile.
Both paths speak the same protocol, so an MCP server written once generally works in both environments. The only difference is where the connection is stored and how you enter it. If you've already set up a connection in Claude Desktop, you can bring it into Claude Code with claude mcp add-from-claude-desktop instead of configuring it twice.
Setting up a server: claude mcp add in practice
For a remote service reachable over a web address, the command looks like this:
claude mcp add --transport http <name> <url>
If the server instead runs as a local program that Claude Code starts itself, you use this instead:
claude mcp add --transport stdio <name> -- <command>
The difference is easy to remember: HTTP for a service running somewhere on the network or inside your own company network, stdio for a command line program that starts directly on your machine. Once it's set up, check with /mcp in Claude Code whether the connection is working, including any OAuth login the service might require. claude mcp list shows every server you've configured, and you remove one with claude mcp remove. The full command reference is in Anthropic's MCP documentation (code.claude.com/docs/en/mcp).
Understanding scopes: where a connection applies
When you set up a server, you also decide how far the connection reaches. That's called a scope, and there are three of them.
| Scope |
Applies to |
Stored in |
| local |
just you, just this one project (default) |
~/.claude.json |
| project |
anyone who opens the project |
.mcp.json in the project folder |
| user |
you, across every project |
your user profile |
I use local almost everywhere: a connection to Sonja's inbox belongs only in Sonja's own working folder, not in every project I happen to be working on. I only use project where several roles genuinely need the same service, and user where a connection really should apply to me personally across every project, for example a research tool. The narrower the scope, the less a mistake can spread in the wrong direction.
A workday with three connected servers
Here's what that looks like for me in practice, on an ordinary day with three employees who each have their own MCP connection.
Sonja has a connection to my inbox. In the morning, she sorts new mail, spots meeting requests, and drafts a reply in my own voice for each one. She doesn't send anything herself, sending stays with me, but I only have to check and approve the reply instead of writing it from scratch.
Susi has a connection to an ad account. When a campaign runs outside the planned budget, she flags it with the numbers from the account and suggests an adjustment. She doesn't change the figure herself, that stays a decision I make before anything actually changes in the account.
Peter has a connection to bookkeeping. He reads in new receipts, assigns a category, and prepares the booking entry. Whether the category is right, especially anything with tax relevance, is still a call I make, and Peter just puts the checked draft in front of me.
The pattern is the same for all three: the MCP server gives that employee access to real data, and the actual decision with outward effect stays with me.
Security rules: which servers, which rights
Before I connect a server, I ask myself two questions: who owns the server, and exactly what is it allowed to do on my behalf. A server whose source I don't know or whose code I haven't reviewed doesn't get a production connection from me, no matter how useful it sounds.
Extra caution applies to servers that load external content themselves, from the web or from files someone else controls. Anthropic's documentation explicitly warns about prompt injection with servers like that: manipulated content in a loaded page or file can try to slip Claude instructions that should actually be coming from you. It helps to keep two things apart here: the technical permission and the behavioural rule. What technically bounds an access is the set of tools a server offers at all, the rights of the credential behind it, the OAuth scopes of an account for instance, and the tool permissions in Claude Code (Claude Code documentation on MCP). That boundary holds even when a manipulated file successfully talks Claude into something: what the credential cannot do, Claude cannot trigger either. A rule in a personnel file, by contrast, is a behavioural instruction, and it is weakest at exactly the moment it would matter most. So I use both and rely on the technical boundary for anything that would really hurt. Sonja's inbox access is configured to read and drop drafts, but not to send. Susi's ad account access can pull numbers, but not change budget. Anything beyond that I approve explicitly, case by case, and the AI employee records that approval with a timestamp in its own log.
I also watch the scope: a connection with far reaching rights belongs in the narrowest scope that still works, not in user just because that's more convenient. And when a server is no longer needed for a task, I remove it with claude mcp remove instead of leaving it connected unused.
Frequently asked questions
Does an MCP server cost extra?
The MCP server itself is separate from your Claude plan, what it costs depends on the service it connects to. Some servers are free open source projects, others belong to a paid product with its own price. The prices of the Claude plans themselves, independent of MCP, are in Claude Code Pricing: Plan or API?.
What's the difference from connectors in Claude Cowork?
Connectors are a feature in Claude Cowork that bundle prepared connections to services without you typing a command yourself. MCP is the underlying protocol that both connectors and manually configured servers in Claude Code speak. If you want the two tools compared side by side, that's in Claude Code or Cowork: What For?.
Can an MCP server leak data?
Yes, if you give it more rights than its task needs, or if you use a server from a source you haven't reviewed. That's exactly why I scope rights per role and avoid servers whose origin I don't know, as described in the security rules section above.
Do I need to know how to code to set one up?
For the three commands claude mcp add, claude mcp list, and claude mcp remove, it's enough to type them from the instructions and fill in the values for the service you're connecting. Some technical understanding helps if you want to write a server yourself, but for simply connecting a finished server, it isn't necessary.
How do I figure out which servers I actually need?
I don't start with a list of possible servers, I start with the question of which task is currently stuck for lack of real data. Sonja's inbox connection only came after it was clear she could only produce generic text blocks without real mail access, not because a server catalog recommended it.
Where to go from here
If you haven't set up Claude Code yet, it's worth reading Claude Code: A Guide for Beginners first, it covers installation and your first task in the terminal. Once an MCP server is running, the next useful step is often to not use it directly in your main conversation, but through a dedicated subagent with clearly limited rights. How that connects is in Claude Subagents, Skills, Agents. And if you want to build your own agent for a recurring task right after connecting a server, the steps are in Build an AI Agent With Claude: A Guide.
Which MCP connections an employee actually gets is your call, based on your own setup. All eight ready-made AI employee packages, each with a clearly bounded role, are in my community.
