Claude Code as MCP client and server
Out of the box, Claude Code's toolset is deliberately small: read files, edit files, run commands, search. Everything else (your browser, your database, your issue tracker) arrives over MCP. The less-noticed part is that the connection runs both ways: Claude Code consumes MCP servers like any client, and it can also stand up as an MCP server itself, lending its tools to other programs. Both directions are useful. Both have sharp edges.
If the protocol itself is fuzzy, the MCP primer covers how it works; this piece is about the wiring.
Consuming servers: scope is the real decision
Adding a server is one claude mcp add command pointed at a local process or a remote endpoint. The decision that matters is scope, because scope decides who else gets the server.
- Local. The default: private to you, in this project only. Right for experiments and anything carrying your personal credentials.
- Project. Written to a
.mcp.jsonchecked into the repo and shared with everyone who clones it. Right for servers the team's workflow genuinely assumes; Claude Code asks for approval before trusting one it has not seen, for reasons we will get to. - User. Follows you across all your projects. Right for the personal utilities you want everywhere.
Remote servers authenticate over OAuth, and the /mcp command inside a session shows what is connected and handles the login. My rule: a server earns project scope only when some task in the repo fails without it. Everything else starts local and has to prove itself.
Serving: Claude Code as the backend
Run claude mcp serve and the arrow flips: Claude Code exposes its own tools (reading, editing, running commands) as an MCP server other clients can drive. Wire it into a desktop client and that client operates on your local checkout with the same battle-tested file tools the CLI uses. If you build agents, this is quietly the more interesting direction: instead of reimplementing careful file editing, you borrow it. It pairs well with the thinking in designing agent tools: fewer, sharper tools beat sprawling ones, whichever side of the protocol you sit on.
Every MCP server you connect is a standing charge against your context — its tools bill you before you ever call them.
The context bill, and the trust bill
Here is the failure mode nobody puts in the README. Every connected server contributes tool definitions: names, descriptions, schemas. They load whether or not you use them. A few enthusiastic servers can mean dozens of tools sitting in context before your first prompt. Recent builds soften this with deferred tool loading: schemas fetched on demand when the model actually searches for a capability. But mitigation is not a license to hoard. As of this writing my default is zero servers, plus whichever one the current task actually needs.
Trust is the second bill. A sloppy or malicious MCP server is a prompt injection surface: its tool descriptions enter your context, and its outputs steer your agent. A project-scoped .mcp.json means running what a teammate committed. That's exactly why the approval prompt exists, so read it instead of reflexively accepting. None of this is a Claude quirk; Gemini CLI's MCP support carries the same calculus, because it is a property of the protocol.
One filter before you add anything: if a good CLI exists, you may not need a server at all. The agent can already run gh, psql, or curl in its shell. MCP earns its keep where no decent CLI exists, where auth is stateful, or where the integration must hold a session open: a live browser, a long-lived database connection. Wire those, skip the rest, and prune whenever the /mcp list scrolls past a screen. The protocol is the easy part. The discipline is the feature.