Claude Code MCP Servers: Setup, Scopes and Good Defaults

To add an MCP server to Claude Code, run claude mcp add with a name and either a remote URL or a local command, then check it with claude mcp list. Servers can be stored for one project, shared with a team or kept for all your work. Start with one read-only server and confirm it before adding more.

The add command in practice

Claude Code is a terminal-based coding agent, and its MCP support is driven by the command line. For a hosted server over HTTP the pattern, as shown on BusinessMCP’s Claude Code page, looks like this:

claude mcp add --transport http businessmcp \
  https://businessmcp.com/api/mcp \
  --header "Authorization: Bearer mcph_your_key_here"

That page says the server then becomes available to every session in the chosen scope, and that the same endpoint also works with other clients such as Claude Desktop and Cursor. Local servers use a different form, where you give a command to launch instead of a URL. Anthropic’s documentation for Claude Code and MCP is the authority on flags, which have changed between versions, so check it rather than copying old blog posts.

Key takeaway: treat claude mcp add like installing software. A server entry can run commands or hold tokens, so add only what you would be comfortable running yourself.

Scopes: who gets the server

Scope decides where the entry is saved and who shares it. The documentation describes three levels, roughly: private to you in one project, shared with the team via a project file, or available to you everywhere.

Scope idea	Stored	Best for
Local to you, one project	Your own settings	Experiments and personal keys
Project, shared	A file in the repository	Servers the whole team needs
User, all projects	Your user settings	Utilities you use every day

Do not commit secrets into the shared file. Use environment variable expansion where the docs allow it, and give each teammate their own key. That keeps the shared file reviewable and makes it possible to revoke one person’s access.

A coding-focused starter set

Directories help you pick. BusinessMCP’s Dev Tools category lists GitHub and Vercel as Official, and Git, Filesystem, Fetch, GitLab, Prisma, Netlify and Railway as Verified, among others. Our own guide to the best MCP servers for developers goes further. A balanced first set looks like this:

1. Git or GitHub for repository state, diffs and pull requests.
2. A read-only database server so the agent can inspect real schemas, see best database MCP servers.
3. A docs or fetch server so it reads current documentation instead of guessing.
4. Your deploy platform, only once you are comfortable, and ideally with a restricted token.

The full catalogue sits in the BusinessMCP MCP server directory, and our MCP servers list explains how to read its labels.

Authentication and approvals

Remote servers usually authenticate through OAuth or a bearer key. The MCP specification’s authorization section describes OAuth-based flows for remote servers, and BusinessMCP notes that many deployments also accept long-lived keys. Prefer OAuth where offered because access can be revoked from the provider’s side without editing local files.

Claude Code also asks before running tools, depending on your permission settings. Resist the urge to allow everything. Allow read tools broadly and keep write tools on prompt, at least until you have watched the agent use them a few times.

Troubleshooting checklist

• Run claude mcp list and confirm the server shows as connected.
• Inside a session, open the /mcp view to see status and re-authenticate.
• If a local server fails, run its command by hand in a terminal to see the error.
• If tools are missing, check that your key has the scope that exposes them.
• If the agent keeps choosing the wrong tool, remove an overlapping server.
• If things are slow, disable servers you are not using; tool descriptions consume context.

Security habits for coding agents

A coding agent with a shell, a repository and a deploy token is powerful. The MCP project publishes security best practices worth reading before you scale up. In short:

• Prefer servers whose source you can read.
• Keep tokens narrow: repository-scoped, read-only where possible.
• Be wary of content the agent reads from the web or from issues, since text in those places can try to steer it. Our piece on are MCP servers safe explains this prompt injection risk.
• Review any command before approving it.
• Rotate keys when people leave the team.

Hosted versus local for a team

If several developers need the same remote tools, a hosted endpoint saves repeated setup, which we discuss in remote MCP servers. If you work alone on a laptop, local servers are simpler and keep everything on your machine. Both work from the same client. Confirm each server’s details on its own page, because versions and flags move quickly.

A sample team convention

Teams often benefit from writing down a short convention so that servers do not multiply unchecked. A workable version has five lines: servers shared through the project file are reviewed in a pull request like any other change; secrets come only from environment variables; each server’s tool list is pasted into the pull request description; write-capable servers need a second reviewer; and the file is revisited each quarter. The BusinessMCP directory is a useful place to check a candidate’s listing, labels and tool names while reviewing such a pull request.

This turns a personal convenience into an auditable piece of configuration, which matters because a shared server definition is effectively a set of commands your teammates’ machines will run.

Updating and removing servers

Remove a server with the matching claude mcp remove command when you stop needing it, and check claude mcp list afterwards to confirm it is gone from every scope you used. If you shared it through the project file, also delete the entry there and mention it in the pull request so teammates drop it locally. Stale entries are a quiet source of confusion and, if the server holds a key, a quiet source of risk.