Add MCP Servers to Claude Code

Add the first Claude Code MCP server only after you can say what it may read, what it may change, and who owns the configuration. The command to add a server is the easy part. The team work is choosing a narrow integration, keeping secrets out of the repo, and proving the first task is safe.

I would start with one read-only service in a Claude Code workshop, often GitHub issue and pull request context, before adding Slack, Jira, database, or document access. MCP desktop habits can be too broad for repo work because a personal desktop config often reflects one person's convenience, not a shared engineering boundary.

Start with the smallest useful server

Pick the server that removes a real lookup from the Claude Code workflow. Do not add a whole suite of integrations on day one.

For a public repo like vercel/next.js, a useful first pattern would be read-only GitHub context: issues, pull requests, labels, and linked discussion. That helps Claude Code explain why a test or API changed without giving it authority to rewrite tickets, post comments, or touch release state.

This belongs with Team conventions, not personal preference. Once a server can see company data, the repo needs a shared rule for what the agent may use and what a human must still verify.

Use this add-server sequence

When a runbook says “claude code add mcp server”, make it mean this sequence rather than a pasted one-liner.

1. Name the job the server performs, such as “read GitHub PR context for code review.”
2. Choose the scope: local experiment, project convention, or managed team configuration.
3. Add the server through the supported Claude Code MCP setup path, with environment variables supplied outside committed files.
4. Open Claude Code and confirm the server is visible before asking for any work.
5. Run one read-only task first, such as “summarize the issue links for this branch.”
6. Check the transcript or tool calls for unexpected access.
7. Record the permission note before promoting the setup to the team.

In our Delegate, Review, Own method, this sits in Review: the agent can fetch context, but a developer still checks what was fetched and why before trusting the answer. I explain that workflow in our methodology, because MCP makes review evidence more important, not less.

For the broader configuration surface, keep Configure Claude Code MCP Servers nearby, but do not turn every available server into a default dependency.

Choose local, project, or managed scope

Use local scope when one developer is testing whether the integration earns its place. Local is also the right place for personal MCP desktop imports, because the team has not agreed to the same tools or risks yet.

Use project scope only when the repo needs that context regularly. A repo that reviews database migrations might need a schema documentation server, while a frontend package might only need design or issue context.

Use managed configuration when the organization wants consistent access and permissions across Claude Code teams. That is where ownership matters most, because a broken server or overbroad token can affect more than one repo.

Keep permission notes close to the integration

A server that only reads documentation is different from one that can create tickets, update records, or query production-like data. Write that difference down in ordinary language.

Do not hide the boundary in CLAUDE.md unless the memory is only about when to use the integration. The access rule belongs with the MCP configuration or the team runbook, because that is where someone will look when the server changes.

Claude skills can sit beside this pattern when the team needs a repeatable workflow, such as “prepare release notes from PR metadata.” The skill should describe the workflow. The MCP server supplies the external context.

Copy this MCP permission note

This table is intentionally small. If the team cannot fill it in, the server is not ready for a shared Claude Code workflow.

Common questions

Should we import every MCP desktop server into Claude Code?

No. Treat MCP desktop config as a personal starting point. Promote only the servers that support repo work and have a clear owner.

Further reading

• Claude Code docs
• Claude Code skills
• MCP specification

Make the first server boring

Pick one read-only integration and write its permission note before anyone adds it to shared config. If you want to practice this as a team exercise, our hands-on training covers Claude Code MCP setup and review habits.