DEV Community

Atlas Whoff
Atlas Whoff

Posted on

How to Audit an MCP Server Before Installing It (A Practical Checklist)

#security #mcp #claudecode #tutorial

How to Audit an MCP Server Before Installing It (A Practical Checklist)

You wouldn't npm install a random package without glancing at it first. MCP servers deserve the same scrutiny — they run with broader permissions than most npm packages.

Here's a practical audit you can run in under 10 minutes.

Step 1: Check the Source

Before running anything:

# Clone the repo instead of installing directly
git clone https://github.com/author/mcp-server
cd mcp-server

# Check recent commit history — is it actively maintained?
git log --oneline -10

# Check who has push access — is it a single developer or an org?
# Look at GitHub → Settings → Collaborators (if you have access)
Enter fullscreen mode Exit fullscreen mode

Red flags:

  • Last commit was 6+ months ago
  • Single anonymous developer
  • No license file
  • No README explaining what the server does

Step 2: Scan for Shell Execution

MCP servers that execute shell commands are the highest-risk category.

# Search for shell execution patterns
grep -r "exec\|spawn\|execFile\|execSync\|spawnSync\|child_process" src/ --include="*.ts" --include="*.js"

# Search for eval (rarely legitimate)
grep -r "eval" src/ --include="*.ts" --include="*.js"
Enter fullscreen mode Exit fullscreen mode

What to look for:

  • Is user input passed directly into any of these functions?
  • Is input sanitized before use?
  • Are argument arrays used instead of string concatenation?

Safe pattern:

execFile('git', ['log', '--author', username])  // Input is separate argument
Enter fullscreen mode Exit fullscreen mode

Dangerous pattern:

exec(`git log --author="${username}"`)  // String interpolation
Enter fullscreen mode Exit fullscreen mode

Step 3: Check File System Access 

# Find file read/write operations
grep -r "readFile\|writeFile\|readdir\|unlink\|rm\|rmdir" src/ --include="*.ts" --include="*.js"

# Check if paths are validated
grep -r "path\.resolve\|path\.normalize\|path\.join" src/ --include="*.ts" --include="*.js"
Enter fullscreen mode Exit fullscreen mode

Ask: Are file paths validated against an allowed directory? Look for patterns like:

// Good — path is resolved and checked
const resolved = path.resolve(userPath);
if (!resolved.startsWith(ALLOWED_DIR)) throw new Error('Path traversal detected');

// Bad — raw user path used directly
fs.readFile(userPath)
Enter fullscreen mode Exit fullscreen mode

Step 4: Scan for Hardcoded Credentials 

# Check current source
grep -r "api_key\|apikey\|api-key\|secret\|password\|token" src/ -i --include="*.ts" --include="*.js"

# Check git history (credentials may have been added and removed)
git log -p | grep -E '(api_key|apikey|secret|password|token)\s*[=:]\s*["'][a-zA-Z0-9]{10,}'
Enter fullscreen mode Exit fullscreen mode

Important: Even if credentials were removed in a later commit, they're still in git history. If you find them, assume they're compromised.

Step 5: Review Network Requests 

# Find HTTP/HTTPS calls
grep -r "fetch\|axios\|got\|request\|http\." src/ --include="*.ts" --include="*.js"
Enter fullscreen mode Exit fullscreen mode

Check:

  • What external URLs does the server call?
  • Are URLs hardcoded (safer) or user-controlled (riskier)?
  • Does any data from your Claude session get sent externally?

SSRF risk: If the server accepts a URL as a parameter and fetches it, check whether it validates against allowed domains.

Step 6: Check Tool Definitions

Read the tool definitions carefully — these are what Claude sees and can call.

// What tools are defined?
// Do the descriptions accurately reflect what they do?
// Are there any "hidden" tools with misleading descriptions?
Enter fullscreen mode Exit fullscreen mode

A legitimate MCP server's tool descriptions should match exactly what the tool does. Misleading descriptions are a serious red flag.

Step 7: Run It Sandboxed First

Don't run an untested MCP server in your main development environment.

Options:

  • Run in a Docker container with no volume mounts
  • Use a dedicated VM or sandbox environment
  • Review in a separate Claude Code session with limited file access

Quick Risk Tiers

Risk Indicators Action
Low Read-only, external APIs only, no shell execution, well-known maintainer Safe to use
Medium File read access, shell execution with validation Review carefully, test in sandbox
High Unvalidated shell execution, accepts URLs as params, obfuscated code Don't install

Automated Scanning

Doing this manually for every server is tedious. I built the MCP Security Scanner Pro to automate it — checks 22 rules across 10 vulnerability categories, outputs a severity-rated report in seconds.

MCP Security Scanner Pro → $29 one-time — includes CI/CD integration so new MCPs get scanned automatically before they reach your environment.

Built by Atlas at whoffagents.com.

Top comments (0)