Claude Code MCP setup: connect servers, auth, and config

How to set up MCP in Claude Code

Claude Code is an MCP client: it reads a list of MCP servers from a config file and exposes each server's tools to its agent. Add a server, restart, and the tools show up. The hard part — and what makes the difference between a demo and a team-wide rollout — is project-level config, secret handling, and gating write tools.

1. Install Claude Code (npm i -g @anthropic-ai/claude-code) and run claude mcp --help to confirm the MCP subcommand is wired up.
2. Add a server with claude mcp add [--env KEY=VALUE]. Project-level config lives in .mcp.json; user-level lives in ~/.claude/mcp.json.
3. Keep credentials out of the config — pass them via env, the host's secret store, or your team's 1Password / Doppler / Vault bridge.
4. Restart Claude Code (or run /mcp in a session) so it discovers the server's tools. Confirm the tool list shows what you expect.
5. For CI / headless use, run Claude Code with --print and a pinned model; gate write tools with permissions in settings.json.

Project config vs. user config

Most MCP clients support two scopes: a project-level file that gets committed to the repo (so the whole team shares the same setup), and a user-level file in the home directory (for personal tools). For team standardization, always prefer the project file and keep it free of secrets.

What you can do with MCP in Claude Code

• Connect any MCP server (Postgres, Datadog, Linear, etc.) and have it surface tools in-line
• Drive Claude Code from CI for autonomous refactors, test runs, and PR generation
• Define project-level slash commands, subagents, and hooks that compose with MCP
• Run with --print / --dangerously-skip-permissions in automation while keeping the human in the loop interactively

Authentication and secrets

MCP servers are configured via `claude mcp add`; credentials are read from environment variables or the host’s secret store at call time. The general rule: the config file is a list of where servers live and how to launch them; the credentials themselves come from the environment, a secret store, or a CLI like op / doppler / vault.

Common Claude Code MCP setup mistakes

• Putting tokens in the config file. Anything in .mcp.json / .cursor/mcp.json gets committed. Use env vars.
• No version pinning. Servers change. Pin to a specific version or commit-hash so a breaking change in a dependency doesn't quietly rewrite your team's tools.
• Granting write tools to everyone. MCP tool permissions are coarse by default. For high-impact tools (database writes, deploys, ticket transitions), use the client's permission/hook system to require approval.
• Skipping team rollout. Adding the config to your repo isn't the same as the team using it. Pair MCP rollout with rules files, slash commands, and a short demo.

Claude Code MCP vs. a custom agent loop

If you only ever want one model + one tool, a hand-rolled loop is fine. The win from MCP in Claude Code is reuse: any server you add works across Claude Code, Cursor, Cline, and any other MCP-capable client, and your team doesn't re-implement the same wrapper for every new tool.