Most MCP Servers Are a Security Liability
MCP had a great year. Every tool ships one now, every database has a community server, and the protocol genuinely deserves the attention. It solved a real problem: AI clients and external services finally have a common language.
It also created a new one. Most of the MCP servers I see in the wild are built like internal scripts and deployed like production infrastructure, and those are not the same standard.
I want to be specific, because "MCP is insecure" is a lazy take and not what I mean. The protocol is fine. The implementations are where it goes wrong.
The credential problem
Walk through a typical install. You add a database MCP server to your client config, and to make it work you paste a connection string into a JSON file on your laptop. That file is now sitting in plaintext in your home directory, readable by every process you run, synced to wherever your dotfiles go, and one screen-share away from being on someone else's screen.
The server didn't do anything wrong. The install pattern did. We took the thing we spent a decade teaching people to never put in plaintext and made it step one of the setup.
The "it just runs whatever" problem
A lot of database MCP servers take the query the model generated and run it. That's the feature. It's also the hole.
If the server doesn't parse and validate the query before executing it, then the model's output is the security boundary, and the model's output is influenced by whatever's in its context. If any of that context came from your data — a support ticket, a user's display name, a row someone else wrote — you have a prompt-injection path straight to your database. I went deep on that specific attack in prompt injection at the SQL layer, but the headline is simple: "the model wrote it" is not the same as "it's safe to run."
The over-permissioned default
The third pattern is the most common and the most boring. The server connects with whatever credentials were handy, which usually means the application's main database user, which usually means full read and write. Nobody decided the agent should be able to DELETE. It just inherited the ability because making a scoped role was an extra step and the demo worked without it.
Defaults are policy. If the easy path grants write access, write access is what everyone ships with.
What a server should actually do
I'm not neutral here, I build one. But the checklist isn't proprietary, and you should hold any MCP server you adopt to it:
It should never ask you to store a raw credential in a config file. It should parse every query and enforce read-only by understanding the SQL, not by trusting a flag. It should cap result size so a wide query can't dump your whole table into a model's context. It should time out slow queries. And it should log every call, because the first time something weird happens, the log is the only thing that tells you what actually ran.
If the server you're evaluating does the first three and skips the rest, it's a convenience tool, not a security boundary. Fine for a local SQLite file. Not fine pointed at production.
The uncomfortable part
The reason this is worth writing about is that the failure is invisible until it isn't. An over-permissioned, no-logging MCP server works perfectly right up until the day it doesn't, and on that day you have no record of what happened. Convenience tools fail quietly. Security boundaries fail loudly, on purpose, because failing loud is the job.
I built QueryBear because I wanted the convenience of MCP without inheriting the install pattern's security debt. You don't have to use it. But whatever you do use, ask it the boring questions before you point it at anything that matters. Where does the credential live? What stops a write? What's the record when it goes wrong? If the answers are "a config file," "nothing," and "there isn't one," you don't have an MCP server. You have a liability with good ergonomics.