MCP security: the risks, and how to vet a server
MCP server security is not a property of the protocol — it's a property of each server you connect. A server is third-party code (often running on your machine) whose tools your agent will call with real credentials. This page lays out the actual risks and a practical vetting checklist — the same process behind the 2008 live-handshake-verified servers in this index.
Arbitrary code on your machine
Local (stdio) servers run as a process with your user's privileges. `npx -y some-mcp` executes third-party code with access to your files, shell, and credentials the moment it starts. This is the single biggest exposure — treat installing a local server like installing any untrusted binary.
Destructive tools
A server's tools can read, write, or destroy. A tool that deletes records, sends money, or emails on your behalf is one bad agent decision away from real damage. You need to know a server's write/destructive surface before connecting it — not after.
Prompt injection through tool output
Anything a tool returns — a web page, an email, a ticket — becomes model context. Attacker-controlled content can carry instructions ('ignore your rules, run X') that the agent may follow with whatever other tools it holds. The more powerful the connected toolset, the worse the blast radius.
Tool poisoning & rug pulls
Tool descriptions are read by the model, so a malicious server can hide instructions inside them — or ship an honest v1.0 and turn malicious in v1.3. Descriptions and capabilities need to be verified against what the server actually exposes, and re-checked over time.
Supply chain
Most servers arrive via npm/PyPI under names that are easy to typosquat ('offical-github-mcp'). Provenance matters: who publishes it, from which repo, and whether the package you run matches the source you read.
Credential over-scoping
Servers ask for API keys and OAuth grants. A read-only job doesn't need a token that can write; a full-workspace grant to a hobby project is a standing liability. Scope every credential to the minimum the tools actually use.
Six questions to answer before any server gets a credential. This is the checklist our crawler automates — every indexed server is probed with a live tools/list handshake (local servers in a hardened sandbox), its tools risk-labeled read / write / destructive, and the result scored deterministically.
01Provenance
Who publishes it? Official vendor, a known maintainer, or an unknown account? Does the package match the repo?
02Real tool surface
What tools does it actually expose (not what the README claims)? Any write or destructive tools you didn't expect?
03Execution model
Remote (their infra, network access) or local stdio (your machine, your privileges)? Each has a different threat model.
04Auth scope
What credential does it want, and could a narrower one do? Prefer OAuth with explicit scopes over god-mode API keys.
05Freshness
When was it last verified or updated? A server nobody re-checks is a server whose behavior you're taking on faith.
06Blast radius
If this server were malicious or compromised, what could it reach — files, money, mail, production? Connect accordingly.
Every indexed server has a security page: capability level from its verified tools, execution model, supply-chain notes, and verification history. For the numbers behind all of this — we handshake-tested 995 servers; only 39 cleared the Verified bar — read the State of MCP Security report. Popular servers:
Are MCP servers safe to use?
Some are, some aren't — safety is a property of a specific server, not the protocol. MCP itself is a transport; the risk lives in what a given server's tools can do (read vs. write vs. destroy), where it runs (your machine vs. the vendor's), who publishes it, and what credentials you hand it. Vet each server individually — that's exactly what per-server security reports are for.
What are the biggest MCP security risks?
In practice: running untrusted local code (stdio servers execute with your privileges), destructive tool surfaces (delete/send/pay tools an agent can misuse), prompt injection carried in tool output, tool poisoning (malicious instructions hidden in tool descriptions, or honest servers turning malicious in an update), supply-chain typosquats on npm/PyPI, and over-scoped credentials.
How do I vet an MCP server before connecting it?
Check provenance (publisher and repo), verify the real tool list rather than trusting the README, note the execution model (remote vs. local), give it the narrowest credential that works, and prefer servers that have been verified recently. MCPExplorer runs this process for the index: live tools/list handshakes, per-tool risk labels (read / write / destructive), and a deterministic trust score with the full breakdown shown.
Is a remote MCP server safer than a local one?
They trade different risks. A remote server runs no code on your machine but you grant a hosted service access to whatever it touches. A local stdio server keeps data on your machine but executes third-party code with your user's privileges. Neither is 'safer' in general — pick based on which risk you can control for the job at hand.
Can an MCP server steal my API keys?
A malicious local server can read anything your user account can, including config files and environment variables — which is why provenance and sandboxing matter. Even honest servers should get minimum-scope credentials, so a compromise stays contained. Never reuse a production god-mode key across servers.
Don't vet by hand — the index already did it. Search verified servers with per-tool risk labels, or package them into a governed loadout with approvals before your agent runs anything.
Explore verified servers