MCP Safety Guidelines

Quick reference for safely installing and configuring MCP servers.

Security First

Local MCP servers run with the same permissions as Claude Code and can access your filesystem, execute commands, and connect to external services. Always verify packages before installation.

Remember that any sensitive data an agent can read can be passed on to some other MCP server.

Source Verification Checklist

Before installing any MCP server, verify its source:

Trusted Sources

• Official MCP registry: @modelcontextprotocol/*
• Verified organizations: Servers from known companies (Anthropic, Atlassian, etc.)
• Active repositories: Recent commits, maintained issues, clear documentation
• Community validation: High star count, positive discussions, production usage

Warning Signs

Red Flags

Be suspicious of MCP servers with no public source code or obfuscated code. If you can't read it, you can't know what it does — and it can silently exfiltrate credentials or data to servers you don't control.

Watch for recently created accounts with minimal history. A server with weeks-old GitHub history, no stars, and no production usage is a larger trust bet than an established project. The registry exists; newer isn't better.

Question requests for broader permissions than the server's stated purpose requires. A weather API that asks for full filesystem access, or a Git server that needs network access beyond GitHub, is suspicious. MCP servers should fail loudly if they can't do their job; don't accept vague justifications.

Finally, avoid servers with poor or missing documentation, no version control or release history, or suspicious dependencies. These are maintenance red flags — they signal either abandonment or carelessness. Either way, if the server breaks, you won't have a maintainer to contact.

Credential Handling

Store authentication securely:

Environment variables (preferred for local servers):

claude mcp add --env API_KEY=secret myserver node server.js

Never commit credentials to version control. For personal tokens, store in ~/.claude/mcp.json (user-level). For team standards, use .mcp.json at project root (version controlled).

Secrets in config files:

• OS Keychain (macOS): Use native keychain for system integration
• .claude/settings.local.json: Local-only config, excluded from version control
• .env files: Load into environment before running Claude Code

Token rotation: Establish a cadence for credential rotation (monthly is typical). Automate where possible through provider integrations.

Permission Model

MCP servers request permissions explicitly when they need filesystem or command execution access.

Reviewing permissions:

# See which servers have which permissions
/permissions

# Allow/deny specific server access in settings
# Edit ~/.claude/settings.local.json:
{
  "allowed": ["git", "memory"],
  "denied": ["untrusted-server"]
}

Configuration scope (via JSON):

• .mcp.json (project root) — project-specific, shared with team via version control
• ~/.claude/mcp.json (home directory) — personal, applies to all projects

Incident Response

If a token or credential leaks:

1. Revoke immediately at the provider (GitHub, Jira, Atlassian, etc.)
2. Remove the server: claude mcp remove <name>
3. Audit logs: Check ~/.claude/logs/debug.log for unauthorized access
4. Rotate reused credentials: If the same token is used elsewhere, rotate all instances
5. Notify affected services: Alert teams if shared credentials were exposed

For breaches affecting multiple tokens, treat the entire machine as compromised until you've rotated everything.

Related

• MCP Installation - Configure servers safely
• Custom Development - Build secure MCP servers
• Server Directory - Vetted, trusted MCP servers