What I learned reading the security notes of 126 MCP servers
I went through the security profile of every server we track. The real risks are boring, concrete, and mostly about what you hand the model — not the protocol.
There is a genre of MCP security content that is technically correct and completely useless: "be careful," "review permissions," "follow best practices." After working through the security profile of all 126 servers in this directory, I want to make a sharper claim.
Most MCP security advice is noise. Three things actually matter. The rest is theater.
1. The tool that runs arbitrary code in your name
The single most dangerous pattern in MCP is a tool that executes whatever the model sends: raw SQL, shell commands, arbitrary HTTP. A database server with an unguarded execute_query doesn't have a vulnerability — it is the vulnerability. The model writes a DELETE with no WHERE, or gets prompt-injected by a malicious web page it just scraped, and the tool faithfully runs it.
This is why I trust a Postgres server that defaults to read-only mode and parses SQL before executing far more than one that's "more capable." Capability without a guardrail is just a bigger blast radius. When you evaluate a server that runs SQL, shell, or code, the only question that matters is: what stops a confused or manipulated model from doing damage? If the answer is "nothing," that's your answer.
2. OAuth scopes you didn't read
The second risk is quieter. You connect an agent to your Google Workspace or your GitHub, the OAuth screen asks for broad scopes, you click accept because you want it to work. Now an agent that can be steered by any document it reads has write access to your whole account.
The fix isn't "don't use OAuth servers." It's: grant the narrowest scope that works, use a dedicated account where you can, and never give a read-the-web agent write-anything credentials in the same session. The combination is the danger — retrieval (which can be poisoned) plus broad write (which can act) is how a benign-looking setup becomes an exfiltration tool.
3. Handing the model your production keys
The third one is a discipline problem, not a software problem. People wire an agent straight to production — live Stripe keys, the prod database, the real cluster — because the sandbox is annoying to set up. Every payments and infra server worth using ships a sandbox/test mode. Use it as the default. Promote to live credentials only once you've watched the agent behave, and gate anything irreversible (a charge, a transfer, a terraform apply) behind a human.
What doesn't deserve your anxiety
- The protocol itself. MCP is a transport. The risk lives in the tools, not the framing.
- "Is this server trustworthy" as a vibe. Replace it with concrete checks: is it read-only by default, what scopes does it request, does it support a sandbox, is it still maintained.
- Local stdio servers leaking data. A local server that talks to your filesystem and sends nothing outbound is one of the safer shapes, not a scarier one — as long as you scope its directory.
The throughline: MCP security is almost entirely about what you hand the model and what stops it from misusing that. Not the protocol, not a checklist, not a vibe. Look at the three things above and you've covered most of the real risk.
Every server in this directory carries crawled security notes and an auth type. Filter to verified servers or check a specific one before you wire it up.