Connecting MCP Servers to Claude Code

Claude Code is an MCP host. Every configured server becomes a set of tools the model can call, resources you can mention, and prompts you can run. The configuration questions are where a server's definition lives, who can see it, how it authenticates and how much of the context window its tools consume. The exam tests the claude mcp commands, the three scopes and the approval model for shared configuration.

Adding a server

The claude mcp add command registers a server. The transport decides the shape:

# Local stdio server launched as a child process
claude mcp add --transport stdio db-tools -- npx -y @example/db-mcp --readonly

# Remote server over Streamable HTTP
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# Remote server with a static header
claude mcp add --transport http internal https://mcp.example.com \
  --header "Authorization: Bearer ${INTERNAL_TOKEN}"

# Environment variable for a stdio server
claude mcp add --transport stdio --env API_KEY=... weather -- uvx weather-mcp

Everything after -- is the command and arguments for a stdio server. claude mcp list shows configured servers and their health, claude mcp get <name> shows one, claude mcp remove <name> deletes it, and claude mcp add-json <name> '<json>' accepts a raw configuration block. The --transport sse option still exists for older servers but SSE is deprecated in favour of HTTP.

Scopes

Scope	Flag	Stored in	Visible to
local (default)	--scope local	~/.claude.json, under the project path	You, in this project
project	--scope project	.mcp.json at the project root	Everyone who clones the repository
user	--scope user	~/.claude.json	You, in every project

When the same server name appears in several scopes, local wins over project, and project wins over user. Project scope is the collaboration mechanism: commit .mcp.json and the whole team gets the server. Because that file could launch arbitrary commands, Claude Code asks each user to approve project servers the first time, and the settings keys enableAllProjectMcpServers, enabledMcpjsonServers and disabledMcpjsonServers let a team or an enterprise decide the default. A committed .mcp.json should never contain secrets; it supports ${VAR} and ${VAR:-default} expansion so credentials come from each developer's environment.

{
  "mcpServers": {
    "db-tools": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/db-mcp", "--readonly"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    }
  }
}

Two more sources exist. claude --mcp-config file.json loads servers for a single run (combine with --strict-mcp-config to ignore every other source, which is what CI pipelines want), and plugins can bundle servers that activate when the plugin is enabled. Enterprises can additionally deploy a managed MCP configuration that users cannot change.

Authentication

Remote servers that require OAuth are authorised from inside a session with /mcp, which opens the browser flow and stores the resulting token; the same menu shows connection status and lets you reauthenticate or clear credentials. Static credentials go in headers or environment variables as shown above.

How servers appear in a session

Tools are named mcp__<server>__<tool> and are permissioned like any other tool, so permissions.allow can contain mcp__github__get_issue for one tool or mcp__github for the whole server. Resources are referenced in a prompt as @server:protocol://path and are fetched into context. Server prompts appear as slash commands in the form /mcp__server__prompt. Tool results are subject to an output size limit (configurable through an environment variable) and large results are truncated with a warning.

Managing context cost

Every connected server's tool definitions are presented to the model. A handful of servers with a few tools each is fine; several servers with dozens of tools each can consume a large share of the context before any work starts. Claude Code mitigates this with tool search: when the combined tool descriptions exceed a threshold, MCP tools are deferred and loaded on demand when the model searches for them. Architecturally, prefer servers that expose a few well-described tools, disable servers you do not need in a given project, and give heavy integrations to a subagent whose context is disposable.

Governance checklist

• Prefer project scope for shared servers and keep secrets in environment variables.
• Review .mcp.json changes in code review like any other executable configuration.
• Use deny rules for destructive MCP tools and ask for externally visible ones.
• Treat MCP tool results as untrusted input, especially from web, email or ticketing servers.
• In CI use --mcp-config with --strict-mcp-config so the run is reproducible.

Exam focus

• claude mcp add --transport stdio|http <name> [-- command] registers a server; list, get, remove and add-json manage them.
• Scopes are local (default, private to you and this project), project (.mcp.json, shared) and user (all your projects); local overrides project overrides user.
• Project servers require per-user approval; enableAllProjectMcpServers and the enabled/disabled lists control the default.
• .mcp.json supports ${VAR} expansion so committed files hold no secrets.
• Tools appear as mcp__server__tool, resources as @server:uri, prompts as /mcp__server__prompt; /mcp handles OAuth and status.
• Tool definitions cost context; tool search defers large MCP tool sets, and --strict-mcp-config isolates CI runs.