Claude Code can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP), an open source standard for AI-tool integrations. MCP servers give Claude Code access to your tools, databases, and APIs.
What you can do with MCP
With MCP servers connected, you can ask Claude Code to:
Implement features from issue trackers: "Add the feature described in JIRA issue ENG-4521 and create a PR on GitHub."
Analyze monitoring data: "Check Sentry and Statsig to check the usage of the feature described in ENG-4521."
Query databases: "Find emails of 10 random users who used feature ENG-4521, based on our PostgreSQL database."
Integrate designs: "Update our standard email template based on the new Figma designs that were posted in Slack"
Automate workflows: "Create Gmail drafts inviting these 10 users to a feedback session about the new feature."
Popular MCP servers
Here are some commonly used MCP servers you can connect to Claude Code:
Installing MCP servers
MCP servers can be configured in three different ways depending on your needs:
Option 1: Add a remote HTTP server
HTTP servers are the recommended option for connecting to remote MCP servers. This is the most widely supported transport for cloud-based services.
# Basic syntax
claude mcp add --transport http <name><url># Real example: Connect to Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp
# Example with Bearer token
claude mcp add --transport http secure-api https://api.example.com/mcp \
--header"Authorization: Bearer your-token"
Option 2: Add a remote SSE server
# Basic syntax
claude mcp add --transport sse <name><url># Real example: Connect to Asana
claude mcp add --transport sse asana https://mcp.asana.com/sse
# Example with authentication header
claude mcp add --transport sse private-api https://api.company.com/sse \
--header"X-API-Key: your-key-here"
Option 3: Add a local stdio server
Stdio servers run as local processes on your machine. They're ideal for tools that need direct system access or custom scripts.
# Basic syntax
claude mcp add [options] <name> -- <command> [args...]
# Real example: Add Airtable server
claude mcp add --transport stdio --env AIRTABLE_API_KEY=YOUR_KEY airtable \
-- npx -y airtable-mcp-server
Managing your servers
Once configured, you can manage your MCP servers with these commands:
# List all configured servers
claude mcp list
# Get details for a specific server
claude mcp get github
# Remove a server
claude mcp remove github
# (within Claude Code) Check server status
/mcp
Plugin-provided MCP servers
Plugins can bundle MCP servers, automatically providing tools and integrations when the plugin is enabled. Plugin MCP servers work identically to user-configured servers.
How plugin MCP servers work:
Plugins define MCP servers in .mcp.json at the plugin root or inline in plugin.json
When a plugin is enabled, its MCP servers start automatically
MCP servers can be configured at three different scope levels, each serving distinct purposes for managing server accessibility and sharing. Understanding these scopes helps you determine the best way to configure servers for your specific needs.
Local scope
Local-scoped servers represent the default configuration level and are stored in ~/.claude.json under your project's path. These servers remain private to you and are only accessible when working within the current project directory. This scope is ideal for personal development servers, experimental configurations, or servers containing sensitive credentials that shouldn't be shared.
# Add a local-scoped server (default)
claude mcp add --transport http stripe https://mcp.stripe.com
# Explicitly specify local scope
claude mcp add --transport http stripe --scopelocal https://mcp.stripe.com
Project scope
Project-scoped servers enable team collaboration by storing configurations in a .mcp.json file at your project's root directory. This file is designed to be checked into version control, ensuring all team members have access to the same MCP tools and services. When you add a project-scoped server, Claude Code automatically creates or updates this file with the appropriate configuration structure.
# Add a project-scoped server
claude mcp add --transport http paypal --scope project https://mcp.paypal.com/mcp
The resulting .mcp.json file follows a standardized format:
For security reasons, Claude Code prompts for approval before using project-scoped servers from .mcp.json files. If you need to reset these approval choices, use the claude mcp reset-project-choices command.
User scope
User-scoped servers are stored in ~/.claude.json and provide cross-project accessibility, making them available across all projects on your machine while remaining private to your user account. This scope works well for personal utility servers, development tools, or services you frequently use across different projects.
# Add a user server
claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic
Choosing the right scope
Select your scope based on:
Local scope: Personal servers, experimental configurations, or sensitive credentials specific to one project
Project scope: Team-shared servers, project-specific tools, or services required for collaboration
User scope: Personal utilities needed across multiple projects, development tools, or frequently used services
Scope hierarchy and precedence
MCP server configurations follow a clear precedence hierarchy. When servers with the same name exist at multiple scopes, the system resolves conflicts by prioritizing local-scoped servers first, followed by project-scoped servers, and finally user-scoped servers. This design ensures that personal configurations can override shared ones when needed.
Environment variable expansion in .mcp.json
Claude Code supports environment variable expansion in .mcp.json files, allowing teams to share configurations while maintaining flexibility for machine-specific paths and sensitive values like API keys.
Supported syntax:
${VAR} - Expands to the value of environment variable VAR
${VAR:-default} - Expands to VAR if set, otherwise uses default
Expansion locations:
Environment variables can be expanded in:
If a required environment variable is not set and has no default value, Claude Code will fail to parse the config.
Practical examples
{/* ### Example: Automate browser testing with Playwright
# 1. Add the Playwright MCP server
claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest
# 2. Write and run browser tests>"Test if the login flow works with test@example.com">"Take a screenshot of the checkout page on mobile">"Verify that the search feature returns results"
``` */}
### Example: Monitor errors with Sentry
```bash theme={null}
# 1. Add the Sentry MCP server
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
# 2. Use /mcp to authenticate with your Sentry account> /mcp
# 3. Debug production issues>"What are the most common errors in the last 24 hours?">"Show me the stack trace for error ID abc123">"Which deployment introduced these new errors?"
Example: Connect to GitHub for code reviews
# 1. Add the GitHub MCP server
claude mcp add --transport http github https://api.githubcopilot.com/mcp/
# 2. In Claude Code, authenticate if needed> /mcp
# Select "Authenticate" for GitHub# 3. Now you can ask Claude to work with GitHub>"Review PR #456 and suggest improvements">"Create a new issue for the bug we just found">"Show me all open PRs assigned to me"
Example: Query your PostgreSQL database
# 1. Add the database server with your connection string
claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
--dsn"postgresql://readonly:pass@prod.db.com:5432/analytics"# 2. Query your database naturally>"What's our total revenue this month?">"Show me the schema for the orders table">"Find customers who haven't made a purchase in 90 days"
Authenticate with remote MCP servers
Many cloud-based MCP servers require authentication. Claude Code supports OAuth 2.0 for secure connections.
1
Add the server that requires authentication
For example:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
2
Use the /mcp command within Claude Code
In Claude code, use the command:
> /mcp
Then follow the steps in your browser to login.
Add MCP servers from JSON configuration
If you have a JSON configuration for an MCP server, you can add it directly:
1
Add an MCP server from JSON
# Basic syntax
claude mcp add-json<name>'<json>'# Example: Adding an HTTP server with JSON configuration
claude mcp add-json weather-api'{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}'# Example: Adding a stdio server with JSON configuration
claude mcp add-jsonlocal-weather'{"type":"stdio","command":"/path/to/weather-cli","args":["--api-key","abc123"],"env":{"CACHE_DIR":"/tmp"}}'
2
Verify the server was added
claude mcp get weather-api
Import MCP servers from Claude Desktop
If you've already configured MCP servers in Claude Desktop, you can import them:
1
Import servers from Claude Desktop
# Basic syntax
claude mcp add-from-claude-desktop
2
Select which servers to import
After running the command, you'll see an interactive dialog that allows you to select which servers you want to import.
3
Verify the servers were imported
claude mcp list
Use Claude Code as an MCP server
You can use Claude Code itself as an MCP server that other applications can connect to:
# Start Claude as a stdio MCP server
claude mcp serve
You can use this in Claude Desktop by adding this configuration to claude_desktop_config.json:
Disable MCP entirely: Remove MCP functionality completely if needed
Option 1: Exclusive control with managed-mcp.json
When you deploy a managed-mcp.json file, it takes exclusive control over all MCP servers. Users cannot add, modify, or use any MCP servers other than those defined in this file. This is the simplest approach for organizations that want complete control.
System administrators deploy the configuration file to a system-wide directory:
Option 2: Policy-based control with allowlists and denylists
Instead of taking exclusive control, administrators can allow users to configure their own MCP servers while enforcing restrictions on which servers are permitted. This approach uses allowedMcpServers and deniedMcpServers in the managed settings file.
Restriction options
Each entry in the allowlist or denylist can restrict servers in three ways:
By server name (serverName): Matches the configured name of the server
By command (serverCommand): Matches the exact command and arguments used to start stdio servers
By URL pattern (serverUrl): Matches remote server URLs with wildcard support
Important: Each entry must have exactly one of serverName, serverCommand, or serverUrl.
Example configuration
{"allowedMcpServers": [
// Allow by server name
{"serverName": "github"},
{"serverName": "sentry"},
// Allow by exact command (for stdio servers)
{"serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]},
{"serverCommand": ["python", "/usr/local/bin/approved-server.py"]},
// Allow by URL pattern (for remote servers)
{"serverUrl": "https://mcp.company.com/*"},
{"serverUrl": "https://*.internal.corp/*"}],
"deniedMcpServers": [
// Block by server name
{"serverName": "dangerous-server"},
// Block by exact command (for stdio servers)
{"serverCommand": ["npx", "-y", "unapproved-package"]},
// Block by URL pattern (for remote servers)
{"serverUrl": "https://*.untrusted.com/*"}]}
How command-based restrictions work
Exact matching:
Command arrays must match exactly - both the command and all arguments in the correct order
Example: ["npx", "-y", "server"] will NOT match ["npx", "server"] or ["npx", "-y", "server", "--flag"]
Stdio server behavior:
When the allowlist contains anyserverCommand entries, stdio servers must match one of those commands
Stdio servers cannot pass by name alone when command restrictions are present
This ensures administrators can enforce which commands are allowed to run
Non-stdio server behavior:
Remote servers (HTTP, SSE, WebSocket) use URL-based matching when serverUrl entries exist in the allowlist
If no URL entries exist, remote servers fall back to name-based matching
Command restrictions do not apply to remote servers
How URL-based restrictions work
URL patterns support wildcards using * to match any sequence of characters. This is useful for allowing entire domains or subdomains.
Wildcard examples:
https://mcp.company.com/* - Allow all paths on a specific domain
https://*.example.com/* - Allow any subdomain of example.com
http://localhost:*/* - Allow any port on localhost
Remote server behavior:
When the allowlist contains anyserverUrl entries, remote servers must match one of those URL patterns
Remote servers cannot pass by name alone when URL restrictions are present
This ensures administrators can enforce which remote endpoints are allowed
List of entries: Users can only configure servers that match by name, command, or URL pattern
Denylist behavior (deniedMcpServers)
undefined (default): No servers are blocked
Empty array []: No servers are blocked
List of entries: Specified servers are explicitly blocked across all scopes
Important notes
Option 1 and Option 2 can be combined: If managed-mcp.json exists, it has exclusive control and users cannot add servers. Allowlists/denylists still apply to the managed servers themselves.
Denylist takes absolute precedence: If a server matches a denylist entry (by name, command, or URL), it will be blocked even if it's on the allowlist
Name-based, command-based, and URL-based restrictions work together: a server passes if it matches either a name entry, a command entry, or a URL pattern (unless blocked by denylist)
289 The `--` (double dash) separates Claude's own CLI flags from the command and arguments that get passed to the MCP server. Everything before `--` are options for Claude (like `--env`, `--scope`), and everything after `--` is the actual command to run the MCP server.289
290 All options (`--transport`, `--env`, `--scope`, `--header`) must come **before** the server name. The `--` (double dash) then separates the server name from the command and arguments that get passed to the MCP server.
296 This prevents conflicts between Claude's flags and the server's flags.297 This prevents conflicts between Claude's flags and the server's flags.
297</Note>298</Note>
466467
467 * **User and local scope**: `~/.claude.json` (in the `mcpServers` field or under project paths)468 * **User and local scope**: `~/.claude.json` (in the `mcpServers` field or under project paths)
468 * **Project scope**: `.mcp.json` in your project root (checked into source control)469 * **Project scope**: `.mcp.json` in your project root (checked into source control)
469 * **Enterprise managed**: `managed-mcp.json` in system directories (see [Enterprise MCP configuration](#enterprise-mcp-configuration))470 * **Managed**: `managed-mcp.json` in system directories (see [Managed MCP configuration](#managed-mcp-configuration))
470</Note>471</Note>
471472
472### Scope hierarchy and precedence473### Scope hierarchy and precedence
831 * Server and prompt names are normalized (spaces become underscores)832 * Server and prompt names are normalized (spaces become underscores)
836For organizations that need centralized control over MCP servers, Claude Code supports two enterprise configuration options:837For organizations that need centralized control over MCP servers, Claude Code supports two configuration options:
837838
8381. **Exclusive control with `managed-mcp.json`**: Deploy a fixed set of MCP servers that users cannot modify or extend8391. **Exclusive control with `managed-mcp.json`**: Deploy a fixed set of MCP servers that users cannot modify or extend
8392. **Policy-based control with allowlists/denylists**: Allow users to add their own servers, but restrict which ones are permitted8402. **Policy-based control with allowlists/denylists**: Allow users to add their own servers, but restrict which ones are permitted
10511052
1052#### Important notes1053#### Important notes
10531054
1054* **Option 1 and Option 2 can be combined**: If `managed-mcp.json` exists, it has exclusive control and users cannot add servers. Allowlists/denylists still apply to the enterprise servers themselves.1055* **Option 1 and Option 2 can be combined**: If `managed-mcp.json` exists, it has exclusive control and users cannot add servers. Allowlists/denylists still apply to the managed servers themselves.
1055* **Denylist takes absolute precedence**: If a server matches a denylist entry (by name, command, or URL), it will be blocked even if it's on the allowlist1056* **Denylist takes absolute precedence**: If a server matches a denylist entry (by name, command, or URL), it will be blocked even if it's on the allowlist
1056* Name-based, command-based, and URL-based restrictions work together: a server passes if it matches **either** a name entry, a command entry, or a URL pattern (unless blocked by denylist)1057* Name-based, command-based, and URL-based restrictions work together: a server passes if it matches **either** a name entry, a command entry, or a URL pattern (unless blocked by denylist)
10571058
1058<Note>1059<Note>
1059 **When using `managed-mcp.json`**: Users cannot add MCP servers through `claude mcp add` or configuration files. The `allowedMcpServers` and `deniedMcpServers` settings still apply to filter which enterprise servers are actually loaded.1060 **When using `managed-mcp.json`**: Users cannot add MCP servers through `claude mcp add` or configuration files. The `allowedMcpServers` and `deniedMcpServers` settings still apply to filter which managed servers are actually loaded.