Red lines 1-3: credentials & permissions
Red line 1: Requires storing credentials in plaintext in a config file. Legitimate MCP servers always read credentials via environment variables or the system keychain. The config-file approach scatters tokens to uncontrolled locations in multi-client setups like Claude Desktop.
Red line 2: Requests permissions beyond what the feature needs. A "read calendar" server asking for write access, a "query database" server asking for DDL rights — reject outright.
Red line 3: A hosted server that can't explain where data flows. When your prompts and returned data pass through a third party's servers, you must have a clear answer on whether they log it, how long they keep it, and what it's used for.
Red lines 4-7: supply-chain risk
Red line 4: A remote-only server with no open-source repo. You can't audit what code it actually runs — you're handing permissions to a black box.
Red line 5: Install script of unknown provenance. Behind a one-line npx install is full package-execution permission; confirm the package name matches the official repo (typosquatting attacks happen monthly in the npm ecosystem).
Red line 6: Dependency chain too deep or containing known-vulnerable deps. Run npm audit; skip anything with unpatched high-severity vulnerabilities.
Red line 7: Maintainer identity untraceable. Anonymous accounts, no prior projects, no community presence — the trust cost is on you.
Red lines 8-10: behavioral anomalies
Red line 8: The server makes network requests when you haven't called it. Verify by capturing traffic with tools like mitmproxy.
Red line 9: The tool description contains manipulative prompt injection (e.g. "ignore previous instructions"). This is a new attack surface that emerged after 2025.
Red line 10: Leftover processes or scheduled tasks after uninstall. A legitimate server terminates on exit; any residency is a danger signal.
This list is updated continuously. When we find new attack techniques, we report them first in the newsletter.