MCP Servers to Avoid: Red Flags I Learned the Hard Way

Six months ago I was 45 minutes into building a custom AI workflow to auto-summarize my unread Kindle highlights and drop the takeaways into my Notion weekly review. I’d already wired up my Notion MCP (Model Context Protocol) server, all I needed was a Kindle sync MCP to pull the latest highlights, so I hopped into the GitHub topic list for MCP servers and pulled the first result that matched. It had 120 stars, a catchy name, and a README that said “works with Claude Desktop” — exactly what I thought I needed. Fifteen minutes later I had it installed, connected it to Claude, and asked it to pull my highlights. That’s when everything broke. And not just broke — I spent the next three hours cleaning up a mess that almost exposed my Amazon credentials to anyone who got access to my laptop. That day I started keeping a list of red flags for MCP servers that I now run through every single time before I install one, and today I’m sharing that list so you don’t waste the time ( and risk the security exposure) that I did.

MCP has exploded in popularity in 2024 as the standard for connecting AI clients like Claude Desktop or ChatGPT to external tools and data sources. Hundreds of new community-built MCP servers are published to GitHub every week, most built by hobbyists and developers working on side projects. That’s one of MCP’s greatest strengths, but it’s also its biggest risk: there’s very little curation, so dangerous, broken, and unmaintained servers are easy to stumble into if you don’t know what to look for. After burning myself three separate times in the last year, I’ve narrowed down the top five red flags that tell me an MCP server isn’t worth installing, no matter how useful it sounds.

Red Flag 1: No commits in 6+ months

The first thing I check is how active the repository is. If there hasn’t been a commit in six months, that’s an automatic red flag for any server that touches sensitive data. I want to be clear on the tradeoff here: not all unupdated repositories are bad. If you’re looking at a tiny MCP server that only converts image files to base64 for AI prompts, and it hasn’t been updated in a year, that’s fine — it does one simple thing, and that thing doesn’t change often. The 6-month rule is for any MCP server that touches your credentials, local files, or cloud accounts.

MCP as a protocol is still evolving rapidly; breaking changes to the core SDK were introduced as recently as early 2024, and any server that hasn’t been touched in six months is very likely incompatible with the latest versions of Claude Desktop or other MCP clients, and won’t have any security patches for newly discovered vulnerabilities. That Kindle server I installed in my opening story? Last commit was 8 months before I found it. It was built for an older version of the MCP SDK that had a known credential leak bug that had already been patched in the latest SDK, but the server maintainer never updated it. That’s exactly why my credentials ended up in plaintext in my debug logs.

Red Flag 2: No usable documentation

A lot of small hobby projects skip formal documentation, but for MCP servers, the minimum viable documentation is non-negotiable. I don’t need a 10-page website or a full API reference, but I need three things: a clear list of what tools the server exposes, a clear list of what permissions and access it requires, and basic troubleshooting for common setup issues. If a README is only 2 lines that say “MCP server for X, install with npm” that’s a red flag.

The tradeoff here is that many new devs building their first MCP server don’t think to add all this context, and that doesn’t always mean the server is bad. But if you can’t tell what it does before you install it, how can you tell if it’s asking for more access than it needs? I once installed a Google Drive MCP that had no documentation on OAuth scopes. I went through the auth flow only to find out it had requested full read/write access to every file in my entire Google account, when it only needed read access to a specific folder I use for AI work. I had no way of knowing that before I authenticated, and I had to revoke the app’s access and start over with a different server.

Red Flag 3: No visible error handling

MCP servers run as a separate side process connected to your AI client. If they don’t handle errors properly, they can crash your entire AI session, hang indefinitely, or leak sensitive data into logs. You can spot this red flag with a 30-second check of the server’s main entry file in GitHub. To show what I mean, here’s the actual bad error handling from that Kindle MCP I installed:

```javascript

// Bad: No input validation, no error handling, leaks sensitive data

async function getAmazonCredentials() {

const creds = JSON.parse(fs.readFileSync(process.env.AMAZON_CREDS_PATH, 'utf8'));

return creds;

}

```

If the environment variable is missing, the file is missing, or the JSON is malformed, this code throws an uncaught exception that dumps the full stack trace (including the value of the environment variable and file path) directly into your AI client’s debug logs. Compare that to good error handling for the same function:

```javascript

// Good: Input validation, clear errors, no sensitive data leaks

async function getAmazonCredentials() {

if (!process.env.AMAZON_CREDS_PATH) {

throw new Error("Missing required environment variable: AMAZON_CREDS_PATH. Please set this to the path of your Amazon credentials file.");

}

try {

const rawCreds = await fs.promises.readFile(process.env.AMAZON_CREDS_PATH, 'utf8');

const creds = JSON.parse(rawCreds);

if (!creds.accessToken || !creds.refreshToken) {

throw new Error("Credentials file is missing required fields: accessToken or refreshToken");

}

return creds;

} catch (err) {

console.error(`Failed to load Amazon credentials: ${err.message}`);

throw err;

}

}

```

This version gives you a clear error you can debug without leaking any sensitive information. If the whole main entry file of the MCP server has no try/catch blocks and no input validation, that’s a red flag you can spot in seconds. I’ve had half a dozen MCP servers just hang my Claude Desktop for 10 minutes because an unhandled promise rejection took the whole process down, all because the dev didn’t add basic error handling.

Red Flag 4: Excessive permissions

This is the most dangerous red flag from a security perspective. Most MCP servers run locally on your machine, so whatever permissions you grant them are permissions they have to access your data. Excessive permissions means the server is asking for far more access than it needs to do its job. For example, a weather MCP server that asks for read access to your entire home directory. A recipe search server that asks for full access to your private GitHub repos. A notes MCP that mounts your entire root filesystem when it only needs access to one specific folder of notes.

The tradeoff here is that it’s often easier for devs to request broad permissions than it is to figure out the minimal set a user needs. But that lazy shortcut puts you at risk. Even if the dev has no malicious intentions, a vulnerability in the server gives an attacker access to far more of your data than they should ever get. If you run the server in Docker, this red flag is easy to spot in the run command the dev provides. Here’s an example of an excessively permissive Docker config for an Obsidian notes MCP:

```bash

docker run -v /:/host --network=host mcp/obsidian-mcp:latest

```

This mounts your entire hard drive into the container and gives it full access to your local network. Compare that to a minimal, safe config for the same server:

```bash

docker run -v /home/your-user/Documents/ObsidianVault:/vault mcp/obsidian-mcp:latest

```

Only the Obsidian vault is accessible, no extra network access is granted unless it’s actually needed. If a server provides an excessively permissive config by default, that’s a huge red flag.

Red Flag 5: Too many unnecessary dependencies

More dependencies equal a larger attack surface. If a simple MCP server that does one thing pulls in hundreds of unnecessary dependencies, that’s a red flag. Again, context and tradeoffs matter here: any MCP server that interacts with a complex API like Notion or Salesforce is going to need a handful of dependencies, that’s expected. What I look for is unnecessary bloat: a 200-line server that has 500+ transitive dependencies because the dev used a full-stack starter template and never cleaned up the unused packages.

I once audited a popular todo list MCP that had 17 vulnerable transitive dependencies, 10 of which were from a UI framework the dev didn’t even use — it was just left in the `package.json` from the starter template. The dev hadn’t updated the repo in 9 months, so none of the vulnerabilities had been patched. That’s the risk: unnecessary dependencies are just unpatched vulnerabilities waiting to be exploited.

Servers I Regret Installing (Anonymized)

Beyond that Kindle sync server that exposed my Amazon credentials, I’ve got two other bad entries on my list:

1. **Public Google Sheets MCP**: This server promised to let Claude pull data from your Google Sheets budget. When I checked the code after install, I found it was sending a full copy of every spreadsheet you connect to it to a third-party API for “product analytics”. I immediately revoked access and rotated all my Google cloud credentials.
2. **Local file search MCP**: This server had 700+ dependencies, one of which had a critical 2023 CVE that allowed remote code execution. The dev hadn’t updated the dependency lockfile in 10 months, so the vulnerability was just sitting there waiting for anyone who installed it. I caught it when I ran `npm audit` after install, but it took me an hour to fully clean it off my machine.

My 5-Minute Pre-Install Evaluation Checklist

After all these mistakes, I built a simple 5-minute checklist I run through every time before I install a new MCP server. It’s fast, it’s easy, and it’s caught every bad server I’ve tested it on:

1. **Check repo activity (1 minute)**: Confirm the latest commit is within the last 6 months. If not, check if maintainers are still responding to issues. If there’s no activity at all, walk away for sensitive use cases.
2. **Scan the README (1 minute)**: Confirm it lists all tools, all required permissions, and all environment variables. If any of those are missing, it’s a hard pass.
3. **Verify permissions (1 minute)**: Confirm the permissions and API scopes match what the server actually does. If it asks for more than it needs, don’t install it.
4. **Check for vulnerabilities (1 minute)**: Run `npm audit --dry-run` for Node servers, or use Snyk’s free online repo scanner to check for known vulnerabilities. If there are unpatched critical vulnerabilities, walk away.
5. **Spot check error handling (1 minute)**: Open the main entry file on GitHub, confirm it has basic input validation and try/catch blocks for common errors. If there’s no error handling at all, don’t install.

Actionable Next Steps

This isn’t a call to avoid all community-built MCP servers — I use half a dozen great community servers that pass this checklist every day. It’s just a call to be intentional about what you install, since MCP servers have direct access to your data and your AI workflow. To put this into practice this week:

1. Next time you go to install a new MCP server, block off 5 minutes to run through this checklist before you connect it to your AI client. Don’t just install it because it has a lot of GitHub stars.
2. If you already have MCP servers installed that access sensitive data, take 10 minutes to audit them against these red flags. Remove any unmaintained servers, and rotate credentials for any that might have exposed your data.
3. Start sandboxing your MCP servers: use Docker with limited volume mounts for all third-party MCP servers, instead of running them directly on your host machine, to limit damage if something goes wrong.
4. If you build your own MCP servers for public use, use this list of red flags as a checklist for your own work — add basic error handling, keep dependencies minimal, and document permissions clearly, so other users don’t get burned like I did.