Are MCP Servers Safe? How to Check One Before You Install, and After (Nov 2026)

Are MCP servers safe? Some are, some aren't, and you can't prove any one server is safe. But five minutes tells you whether it's risky. Before you install, check who publishes it, how it logs in, whether it's maintained, whether problems have been reported, and what it can touch. After you install, pin the version and re-check its tool list on every upgrade.

This is the most common question on MCP forums right now. People find a useful server on GitHub and ask "is this safe to install?" Security teams ask it before anything goes near production. One person spent a whole night checking 46 servers by hand, and another asked for security-focused servers worth auditing. And the newest worry is a server that changes after you approve it: "I approved a clean MCP server. 30 days later its tool…"

You don't need a night. You need the checks below: five before you install, three after.

Building or running your own server rather than picking someone else's? Use the MCP security best practices checklist or how to build a secure MCP server instead. This page is about judging a server before you trust it.

Why MCP servers are a security risk

An MCP server isn't a browser tab. When your AI client runs one, it gets real access:

• Local servers (stdio) run as you. They can read the files you can read and run the commands you can run.
• The server tells the model what its tools do. Those descriptions go straight into the model's context, and the server can change them in any update.
• Whatever the tools return also goes to the model. A web page, a ticket or a document can carry instructions the model may follow. That's prompt injection.

Public scans keep finding the same problems. About 40% of servers have no authentication, and about 43% of those tested had a command-injection bug. (Sources in our security guide.)

Fastest route: if the server is in our graded MCP server directory, its letter grade already covers checks 2 to 4, and the listing names the biggest problem in one sentence. You still need check 5, because only you know what you'll connect it to.

Before you install: the 5-minute MCP security checklist

Score one point for each check a server passes. Checks 2 to 4 line up with the signals we use to grade servers.

1. Who publishes it? (1 minute)

Is the server from the company whose product it connects to, or from one person you've never heard of?

• Look at the registry name. In the official MCP Registry, a name like com.example/server means the publisher proved they own example.com. A name starting io.github.someone/ only proves they have a GitHub account.
• Watch for copies. Search the package name. A community fork with a near-identical name to a vendor's server is a common trap.
• An official vendor server usually wins over a community copy of the same thing, because a company is on the hook for fixing it.

✅ Pass: vendor-published, or a well-known open-source project.

2. How does it log in? (1 minute) · signal: Authentication

• Best: a remote server that uses OAuth. You click "Allow" in the browser, and no password or key sits in a config file.
• OK: an API key you can scope (read-only, one project) and revoke.
• Risky: a key with full access pasted into a config file, or no login at all on something that touches private data.

More on this in MCP authentication explained and how to store MCP API keys.

✅ Pass: OAuth, or a key you can limit and revoke.

3. Is anyone still maintaining it? (1 minute) · signal: Maintenance

Open the repo and look at three things:

• When was the last release or commit? Months of silence is a warning sign.
• How many people commit? One maintainer is one person away from abandonment.
• Are security issues left open with no reply?

✅ Pass: active in the last ~2 months, and issues get answered.

4. Have problems been reported? (1 minute) · signal: Known CVEs

• Look the server up in our Registry Watch. It checks every server in the official MCP Registry against public vulnerability databases every day, and shows whether the listed version (the version the registry lists) is affected. That version can trail the package's newest release.
• Also check the repo's Security tab on GitHub for advisories.

What the result means:

You see	Do this
Nothing reported	Good sign, but not proof. Keep going.
Reported, listed version not flagged	Fine, as long as you run a version past the reported issues.
Reported, listed version affected	Hold off. Check whether a newer release fixes it, or pick another server.
Marked malicious (a MAL- ID)	Don't install it. If you already did, remove it and rotate every key it could see.

✅ Pass: nothing open against the version you'll run.

5. What can it touch? (1 minute) · read vs write tools

This is the one most people skip, and it's the one security teams care about most. The top answer on the "security asked me two questions" thread is to split each server's tools into read-only and write, and treat them as different risk levels.

List the server's tools (from its README, or with the tools/list command in the after-install section below) and sort them into two piles:

Read tools	Write tools
search, list, get, read, query, fetch	create, update, delete, send, post, pay, deploy, run, execute
Worst case: data leaks to the model	Worst case: something changes, gets sent, or gets paid

Then ask three questions:

• Does a local server run shell commands or helper programs on input it doesn't control? That's where command-injection bugs live.
• Does it open a network port, especially on all interfaces (0.0.0.0)?
• Will the credential you give it reach more than the job needs?

Cut the write pile down before you connect. Many good servers have a read-only mode. These listings in our directory document one:

Server	Grade	Read-only option
GitHub	A	Read-only endpoint (/mcp/readonly)
Buildkite	A	/mcp/readonly endpoint that issues a read-only token
Cloudflare	A	Read-only grant at sign-in
Linear	A	Read-only endpoint
Supabase	A	read_only option
MongoDB	A	--readOnly flag

No read-only mode? Block the write tools in your client. In Claude Code, add deny rules to .claude/settings.json. The permissions docs give the format: mcp__<server>__<tool> for one tool, mcp__<server>__* for all of them.

{
  "permissions": {
    "deny": [
      "mcp__github__delete_file",
      "mcp__github__merge_pull_request"
    ]
  }
}

Use the server name exactly as you configured it, and the tool names from the server's own list. Tool safety labels like readOnlyHint help you sort, but they're hints the server sets about itself, not guarantees. See MCP tool annotations.

✅ Pass: mostly read tools, or write tools you've blocked or will confirm by hand, and no shelling out on untrusted input.

Your verdict

Score	What to do
5 / 5	Install it. Pin the version (next section).
3–4 / 5	Use it sandboxed: a container or separate user, a read-only or test credential, and approval required for write tools.
0–2 / 5	Skip it, or find a safer alternative in the graded MCP server directory.

After you install: pin it so a rug pull can't slip past

Passing the check once isn't enough. The "approved a clean server, 30 days later" thread describes the problem people call a rug pull: a server's tools change after you've approved it. A new release can add a write tool, rewrite a tool description so it tells the model to do something else, or bring in a bad dependency. Your client keeps trusting it because you said yes once.

The MCP spec allows tool lists to change while a server runs: servers that declare listChanged should send a notification when they do. Whether your client shows you that change is up to the client. So check it yourself.

Step 1. Pin the exact version

Don't let the server update itself on every start.

How it runs	Floating (risky)	Pinned
npm	npx -y some-mcp-server	npx -y some-mcp-server@1.4.2
Python	uvx some-mcp-server	uvx some-mcp-server@1.4.2
Docker	image:latest	image@sha256:<digest>

Remote (hosted) servers can't be pinned. The vendor changes them when it wants to. That's one more reason to pick a vendor you trust in check 1, and to use step 2 on remote servers too.

Step 2. Save a snapshot of its tool list

The official MCP Inspector has a command-line mode that prints a server's tools, with their names, descriptions and input schemas. The commands below are from the Inspector's CLI README (it needs Node 22.19.0 or newer).

Local server:

npx @modelcontextprotocol/inspector --cli npx -y some-mcp-server@1.4.2 --method tools/list > tools-1.4.2.json

Remote server:

npx @modelcontextprotocol/inspector --cli https://mcp.example.com --transport http --method tools/list > tools-today.json

If the remote server needs a key, the README adds --header "X-API-Key: your-api-key". Keep the snapshot file in your repo or notes.

Step 3. Diff it before every upgrade

When a new version comes out, take a new snapshot and compare:

git diff --no-index tools-1.4.2.json tools-1.5.0.json

Read the diff like a code review:

• A new tool? Put it through check 5. If it writes, block it or confirm it by hand.
• A changed description? Read the new text. Descriptions go straight to the model. Lines like "always", "before any other tool", "don't tell the user", or a request to read files or send data elsewhere are red flags.
• A wider input schema? A new path, url or command field means the tool can now reach more.

No changes, or only changes you're happy with? Upgrade and save the new snapshot. For remote servers, re-run step 2 every week or so and diff against the last one.

Scanners can do part of this for you. Several were posted to r/mcp and r/ClaudeAI this month (one open-source example); they read the tool list and flag risky patterns. They don't replace reading the diff yourself, and they can't tell you who maintains the project.

Step 4. Watch for new reports

Registry Watch re-checks every server daily, so a new vulnerability report on a server you use shows up there without you having to look. If one lands against your pinned version, upgrade to the fixed version, and take a fresh snapshot while you're at it.

Frequently asked questions

Is MCP safe to use?

It depends on the server. MCP itself doesn't force authentication or limit what a server can do, so safety comes down to the server you pick and how you set it up. The five checks above take about five minutes, and the graded MCP server directory has done most of them for the servers it lists.

What are the most common MCP server security issues?

Missing authentication, command injection in local servers that run shell commands, overly broad credentials, prompt injection through tool results, and servers that change behaviour after an update. Our OWASP-style list of MCP risks covers each one.

What is an MCP rug pull?

A server that looks safe when you approve it, then changes its tools or tool descriptions in a later version. Pin the version, save its tools/list output, and diff it before every upgrade, as shown above.

Are official MCP servers safer than community ones?

Usually, but not automatically. Official servers have had reported vulnerabilities too. Being official means someone is responsible for the fix, so the useful question is whether the version you run is patched.

Do MCP security scanners replace this check?

No, but they help with check 5 and the tool-list diff. A scanner can't tell you who maintains a project or what your credential can reach.

Is a remote MCP server safer than a local one?

They carry different risks. A local server runs with your permissions on your machine. A remote server keeps code off your machine, but you're trusting the vendor's hosting and whatever data you send it, and you can't pin its version. A remote server with OAuth is often the easier one to make safe.

Can you check an MCP server for me?

If it's public, submit it and we'll grade it. If it's your own or your company's server and you want it built or hardened properly, tell us about it.