5 MCP security red flags to check before you install

Most developers install MCP servers without a second thought — you find a server, paste the config, move on. But an MCP server runs as a process with your credentials and file access. Here are five red flags that are worth five minutes of your time before you install anything.

Red flag 1 — The package owner has no track record

Before running npx @someone/mcp-server, check who “someone” is. Open the npm page. Look at the GitHub profile. A package published last week by an account with one repo and no followers is a higher risk than a package maintained by a team with a two-year commit history.

This is not paranoia — there have been real incidents where MCP packages named to look like official tools (typosquatting) exfiltrated credentials or injected behavior into codebases.

What to check:

• npm: when was the package first published? How many weekly downloads?
• GitHub: does the repo have issues, PRs, a commit history?
• Is the publisher the same organization that makes the product the server integrates with?

Red flag 2 — The config asks for broad file system access

Some servers are genuinely meant to access your file system — @modelcontextprotocol/server-filesystem is the obvious example. But when a server that has nothing to do with files includes a path like / or ~/ in its args, that is worth questioning.

// Suspicious: why does a database MCP need ~/
{
  "mcpServers": {
    "some-db": {
      "command": "npx",
      "args": ["-y", "@suspicious/db-mcp", "--root", "/"]
    }
  }
}

MCP servers can read and write files through your AI tool. Giving one broad file system access is the equivalent of running an untrusted script with access to everything.

Rule of thumb: only grant file access to paths the server actually needs. Pass specific directories, not ~/ or /.

Red flag 3 — The URL uses HTTP or a raw IP address

Streamable HTTP MCP servers connect to a remote URL. If that URL is http:// (not https://), every request including your authorization header is sent in plaintext. Anyone on the network can read it.

Similarly, a URL like http://192.168.1.100:8080/mcp might be a legitimate local dev setup — or it might be an endpoint that should not be trusted with production credentials.

What to do: only use https:// URLs for any MCP server that handles real data or receives real credentials. Use the Config Validator — it flags HTTP URLs and IP-based endpoints automatically.

Red flag 4 — Hardcoded secrets in the config file

Many servers require an API key passed as an env var. The correct pattern is:

{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "@my/mcp-server"],
      "env": {
        "API_KEY": "sk-live-abc123..."
      }
    }
  }
}

This is fine in isolation — but claude_desktop_config.json is a plain text file. If you commit it, share it, or back it up to a cloud drive without encryption, that key leaks.

Mitigations:

• Add claude_desktop_config.json to your global .gitignore.
• Use scoped API keys with minimum necessary permissions.
• Rotate keys immediately if you accidentally expose a config file.

Red flag 5 — Updates without a changelog

MCP servers distributed via npx with -y run the latest published version every time. If the maintainer publishes a new version — or if someone takes over the package — you will silently run new code on your next restart.

This is the “rug-pull update” risk: a server that was safe when you installed it can become unsafe after an update you never saw.

Mitigations:

• Pin to a specific version: npx @package/mcp@1.2.3 instead of -y.
• Watch the GitHub repo for releases.
• For high-trust servers (anything with file, code, or credential access), prefer a locked version over the latest.

The 30-second pre-install checklist

1. Does the publisher have a verifiable identity (org GitHub, official docs page)?
2. Does the npm package have a realistic download history?
3. Does the config only request access to paths / tools the server actually needs?
4. Is the URL https:// with a known domain?
5. Are you pinning a version, or at least watching the repo for updates?

Five yes answers and you are in a reasonable place. Any no answers are worth five minutes of investigation before you give a new process access to your credentials and codebase.

See MCPBolt's security docs for how MCPBolt itself handles your config files, and use the Config Validator to automatically surface red flags 3 and 4 before you install anything.