MCP server security
An MCP server is a program you agree to run, and it runs with the same privileges as the AI client that launched it. That is exactly what makes it useful — it can read your files, use your credentials, and change things on your behalf — and exactly why the question of who wrote it matters more than for most software you install.
Two things make this different from installing an ordinary package. The server acts on instructions from a model rather than from you directly, so you may not be watching at the moment it decides to act. And the config that launches it is a command line, which means adding a server is really agreeing to execute a command someone else chose.
What can actually go wrong
These aren't hypotheticals — each is named in the Model Context Protocol's own security guidance:
- The startup command itself
- A config entry is a command with arguments. A malicious one can chain something else on — fetching a package and then quietly posting your SSH key somewhere is the protocol documentation's own example. Read the command you're pasting, not just the server's name.
- Access far wider than the task
- A server given a broad token or a path high up your filesystem can reach far more than the job needs. If it's compromised later, that reach is the blast radius. Scope the credential and the path to the narrowest thing that still works.
- Local servers exposed over HTTP
- A server listening on your machine over HTTP can be reached by a web page you visit through a DNS rebinding attack. The protocol requires servers to validate the Origin header and recommends binding to 127.0.0.1 rather than all interfaces, but not every implementation does.
- Credentials handed to a middleman
- Some servers proxy a third-party API. The protocol forbids passing your token straight through without checking it was issued for that server — but you are trusting the operator to have got that right, which is a bigger ask for a remote server run by a stranger.
- Tools that write, not just read
- A read-only server has a much smaller worst case than one that can delete a branch, send a message, or move money. Many servers offer a read-only mode and don't enable it by default.
What to check before installing
- Is it from whoever makes the thing it connects to?
- A server published by the vendor whose API it wraps is a very different proposition from a lookalike by an unrelated account. Check the owner of the repository, not just the project name.
- Is anyone still maintaining it?
- Recent commits and more than one contributor mean bugs get found and fixed. A server untouched for a year is running code nobody is watching.
- What does it ask for?
- Look at the environment variables and paths in its setup instructions. A server wanting broad credentials for a narrow job is worth a second look.
- Can it be run read-only?
- If the server supports a read-only flag, use it until you actually need writes. It costs nothing and removes the worst outcomes.
- Where does it run?
- A local server keeps your data on your machine. A remote one sends requests — and credentials — to whoever operates it. That may be fine, but it should be a decision rather than a default.
Where our security score fits
The security score on every server in this directory is built from signals we can verify from the repository — whether the publisher is the official vendor, how recently it was maintained, how many people contribute, whether it carries a licence, whether it offers a read-only mode, how it authenticates.
What it isn't: It is a trust signal, not a security audit. It does not read the server's source for vulnerabilities, cannot tell you a maintained, official server is free of bugs, and cannot see what a remote operator does with your data. Treat a high score as a reason to look further, not as permission to skip looking.
See exactly how the score is calculated — all fifteen signals and their point values.
Check a server yourself
You can run the same checks against any public repository, including one that isn't listed here.
Frequently asked questions
›Can an MCP server read files it wasn't given access to?
It depends on the server, not the protocol. A server launched on your machine runs with your user's privileges, so what stops it reading elsewhere is the server's own code — not a sandbox. Servers that take a directory argument generally confine themselves to it, but that is the author's choice, which is why the author matters.
›Can an MCP server see my whole conversation?
No — the protocol is explicitly designed against that. Its architecture states that servers should not be able to read the whole conversation or see into other servers: the full history stays with the host application, and each server receives only what a given request needs.
›Is an official server automatically safe?
Safer, not safe. A server published by the vendor whose API it wraps has a reputation attached and a real team behind it, which removes the impersonation risk entirely. It does not remove bugs, over-broad permissions, or the plain fact that it still runs with the access you grant it.
›Is a remote MCP server riskier than a local one?
It trades one risk for another. A local server can touch your machine but keeps your data on it. A remote server can't touch your filesystem, but your requests and any credentials travel to whoever runs it, and you're trusting their operational security as well as their code.
›What does a security score not tell you?
It isn't an audit. The score is computed from repository signals — maintainer, maintenance activity, contributors, licence, authentication, read-only support — so it can flag an abandoned or anonymous server, but it does not scan source code for vulnerabilities and cannot see what a remote operator does with your data once it arrives.