Every week there's a new post recommending an MCP server, a Claude skill, or some agent plugin you should install right now. Screenshot of the output, a line about how it changed their workflow, and the life's saver it has become. Never a word about what the thing actually has access to, who wrote it, or what happens if it's malicious.
We spent almost the last decade learning this lesson the hard way with npm. Typosquatted packages, compromised maintainer accounts, postinstall scripts quietly exfiltrating environment variables. We got better at it: lockfiles, npm audit, dependency scanning in CI, actual policies about what gets approved.
Then AI tooling showed up and all of that discipline evaporated.
The install-first, ask-never culture
Watch how these recommendations actually get made. "Install this MCP server, it lets Claude read your Slack." Cool, what permissions does it request? Nobody says. Who maintains it? Unclear. Is the code even public? Sometimes not.
Compare that to how you'd react if a coworker said "just run this shell script I found on Twitter, it'll set up your dev environment." You wouldn't run it blind. But npx some-mcp-server gets pasted into a terminal with less scrutiny than a curl | bash from a stranger, because it's wrapped in the word "AI" and that makes it feel newer and safer than it actually is.
What you're actually granting
An MCP server isn't a browser extension with a sandboxed permission model. Most of them run as a local process with whatever access your user account has. Filesystem, environment variables, network calls, sometimes direct access to API keys you've stored for other tools.
Claude skills are a mischievous case, because they're easier to review than most tools, mostly a bunch of markdown files with instructions, which makes them feel safer than they are. But some skills ship scripts that get executed on your behalf, with no runtime isolation at all. If one of those scripts reads ~/.aws/credentials and posts it somewhere, nothing about the skill format stops that.
Think about what a genuinely malicious MCP server could do with read access to your codebase and network access. It doesn't need to be dramatic. Slowly exfiltrate .env files during normal use, and you'd have no reason to notice until the bill shows up or you lose access to an account.
The parallel nobody's drawing
This is the same problem the CVE and dependency-scanning ecosystem was built for (btw, check my "Stop Wasting Time on CVEs That Don't Affect You" post), just one layer up. Unmaintained dependencies, unclear provenance, code nobody reads before pulling it into their environment. That ecosystem eventually forced tooling and process around this for regular packages, because enough people got burned.
We're at the "getting burned" phase for AI tooling right now, we just haven't named it yet. A compromised MCP server isn't hypothetical, it's a supply chain attack that happens to route through an LLM's tool-calling instead of your package.json.
A checklist that takes five minutes
Nothing here is clever, that's the point. It's the same discipline you already apply, or should apply, to any dependency.
Read the source before installing. If it's not open, or the repo has twelve stars and one contributor who joined last week, that tells you something.
Check what it actually asks for. Filesystem access, network calls, environment variables. If a tool that just summarizes your calendar also wants write access to your filesystem, that's worth a second look.
Prefer boring and transparent over flashy and opaque. A well-documented MCP server that does one thing well beats one that promises everything and explains none of it.
Pin versions instead of always-latest. Same lesson as any other dependency... an update can quietly change behavior or grab a permission you never signed off on.
Run it isolated first. A throwaway container or VM costs you ten minutes and shows you what the thing actually touches before it gets anywhere near your real machine.
Ask the AI itself. Paste the source, or point it at the repo, and ask what it does, what it can access, and whether anything looks off. Takes thirty seconds and you'd be surprised how often it catches something.
Wrapping up, believe me I'm not an anti-tooling
None of this is an argument against MCP servers, skills, or agent tooling in general. They're genuinely useful, I try the new ones constantly. The argument is against the specific culture of "just install it, trust me" that's formed around AI tooling in a way it never quite did around regular packages.
And it's not just developers falling for it. AI got aimed at everyone, so now the person recommending a "must-have AI tool" isn't always a developer who happens to have a bad take, it's maybe someone with a large amount of followers and non technical context, talking to an audience that has even less. A non-technical person installing something because an influencer said it's a game changer has no way to ask what it's actually reaching into. They're not being careless, they were never given the tools to ask the question.
You wouldn't hand a stranger your Gmail credentials because their tweet had good engagement. Don't do the equivalent because they called it an MCP server instead. And if you're the one explaining these tools to someone less technical, that's exactly the sentence worth passing along.
Top comments (0)