MCP server security: risks and how to evaluate them

An MCP server is a program that an AI assistant can call on its own. It runs with the access you configure — your API tokens, your files, your database connection — and the model decides when to use it. Two things follow from that:

• a server can do anything its credentials allow, not only what you had in mind;
• the model can be steered by text it reads (a web page, an issue, a document), so an action you did not ask for can still be triggered. This is known as prompt injection.

Neither is a reason to avoid MCP. They are reasons to give each server as little access as the job needs.

We scan the README and metadata of 453 servers for signs of what they access:

• 97% use network access;
• 86% can create, update, send, or delete data in another system;
• 85% need an API token or other credential;
• 38% read or write local files;
• 19% connect to a database.

Only 48% document security, permissions, or token scopes. These are documentation signals — a server can do more than its README says, but rarely less.

• Over-broad credentials. A personal access token with full account scope lets the server (and so the model) do everything you can do.
• Destructive actions. Tools that delete, merge, deploy, or send messages can cause damage if called at the wrong time.
• Filesystem reach. A file server pointed at your home folder can read SSH keys, browser data, and environment files.
• Data leaving your machine. Anything a tool returns goes to the model provider; a remote server also sees your requests.
• Supply chain. npx and uvx fetch and run the latest published package each time. A compromised or renamed package runs with your permissions.

• Read the tool list. Do you need every tool? Write and delete tools deserve the most attention.
• Check the token scopes it asks for, and whether it works with read-only scopes.
• Look for a security or permissions section in the README.
• Check who publishes it: the vendor, a known organisation, or an individual.
• Check recent activity — security fixes need an active maintainer.

Each server page on this site shows the signals we detected and a risk level: High if it can write to external systems, a database, or the filesystem; Medium if it needs a credential but shows no write access; Low if it appears read-only and local; Unknown when there is not enough information. Today 397 servers are High, 36 Medium, and 20 Low. A High level is not a verdict — it means "this can change things, configure it carefully". The safest servers list ranks by our safety score.

• Create a dedicated token with the narrowest scopes that work, and set an expiry.
• Use read-only database users and read-only API modes where offered.
• Limit filesystem servers to a specific project folder, never your home directory.
• Pin package versions instead of always running the latest release.
• Keep your client's confirmation prompt on for tools that write or delete.
• Disable or remove servers you are not using.
• Prefer Docker or another sandbox for servers you do not fully trust.

Our risk profiles come from documentation and metadata, not a code audit. They are a starting point for your own review. See how we benchmark MCP servers for what we check and what we deliberately do not run.