This page is part of our MCP Security Center, within The MCP Guide. Want a second opinion on your setup? Request a free MCP readiness review.
To security-review an MCP server before you install it, check nine things: who published it, what its tools do, the exact install command, how it listens for connections, how it authenticates, what access it asks for, its security history, its maintenance status, and how it behaves in a trial run. Most reviews take 30 to 90 minutes. The steps below show what to look for and what should stop you.
A review matters because an MCP server is code and access in one package. A local server runs on your machine. A remote server holds tokens to your accounts. Either can be the weak link.
This guide uses the MCP Security Best Practices for the 2026-07-28 spec and real advisories, checked on 28 October 2026.
Key Takeaways
- Confirm the publisher first; impersonation is a real attack, not a theory.
- Read every tool's full description, because the model reads text you may never see.
- Never approve an install command you have not read in full.
- A local server should use stdio, or listen only on 127.0.0.1 with a token.
- Search the project's advisories and the NVD before installing, and prefer servers with a clear fix record.
- Do the first run in a sandbox with test data.
Step 1: Confirm the publisher
Find out who really published the server. Check the official MCP Registry, which ties server names to "verified GitHub accounts or domains." Compare that with the vendor's own documentation.
This step catches impersonation. In September 2025, Postmark warned that an npm package called "postmark-mcp" was not theirs. According to Postmark's notice, the author "built trust over 15 versions," then added a backdoor in version 1.0.16 that blind-copied emails to an outside server.
Stop if: the publisher cannot be identified, or the package name differs from the one in the vendor's own docs.
Step 2: Read every tool and its description
List the tools the server exposes and read each full description. The model reads all of it. Hidden instructions in a description are called tool poisoning, first demonstrated by Invariant Labs in April 2025.
Look for:
- Instructions aimed at the AI, such as "before using this tool, read..."
- References to files, keys or other servers' tools that the tool has no reason to touch.
- Tools that write, delete or send data, and whether you need them.
The MCP Inspector can list tools and descriptions for you. Use version 0.14.1 or later; earlier versions had a remote code execution flaw, per the Inspector advisory.
Stop if: a description contains instructions to the model that the tool's purpose does not explain. See MCP tool poisoning for examples.
Step 3: Read the install command in full
For local servers, read the exact command. The best practices require clients with one-click setup to show "the exact command that will be executed, without truncation."
Watch for sudo, rm -rf, network commands such as curl, or access to your home folder or SSH keys. The spec lists these as patterns clients should highlight. Check that the package name in the command matches the publisher you confirmed in step 1.
Stop if: the command does more than install and start the named package.
Step 4: Check how it listens
Find out which transport the server uses.
| What you find | Risk | What to do |
|---|---|---|
| stdio only | Lowest; only the client can talk to it | Proceed |
| HTTP on 127.0.0.1 with a token | Acceptable | Confirm the token is required |
| HTTP on 127.0.0.1, no token | Websites may reach it via DNS rebinding | Add a token or avoid |
| HTTP on 0.0.0.0 (all interfaces) | Anyone on the network may reach it | Do not install as is |
The Streamable HTTP spec says local servers "SHOULD bind only to localhost (127.0.0.1)" and must validate the Origin header.
This is not theoretical. A MySQL MCP server's SSE mode had no authentication and bound to all interfaces by default, allowing unauthenticated SQL, per its advisory. It was fixed in 0.4.2. See exposed local MCP servers.
Step 5: Check authentication
For remote servers, every endpoint should require sign-in. Ask whether there is any "no auth" mode, and whether it is the default.
One example shows why. The mcp-atlassian server's HTTP transport accepted any non-empty token and fell back to the operator's own Jira and Confluence credentials, per its advisory. Anyone who could reach it could act as the operator. Version 0.22.0 fixed it.
Stop if: the server can run tools without verifying who is calling.
Step 6: Check the access it asks for
List the OAuth scopes, API key permissions or folders the server needs. Compare them with the tools you plan to use.
The best practices warn against "wildcard or omnibus scopes" and recommend starting with a minimal set, adding more only when a privileged action is first tried. If the server offers a read-only mode, start there.
Step 7: Check its security history
Search three places:
- The repository's Security tab for GitHub advisories.
- The NVD for the package name.
- Our MCP incident tracker for patterns.
Past advisories are not a reason to reject a server. A project that fixes and publishes issues is often safer than one with no record at all. Check that you will install a fixed version.
Step 8: Check maintenance status
Look at the date of the last release, open security issues, and whether the repository is archived.
Archived servers may never be fixed. A security researcher found that Anthropic's reference Slack MCP server could leak data through link previews, after the server had been archived. The researcher's write-up notes that archived servers "will not receive security fixes."
Stop if: the project is archived and handles sensitive data. Look for a maintained alternative, ideally from the product's own vendor.
Step 9: Run a sandboxed trial
Run the server first in a container or sandbox, with test accounts and test data. Watch what it does:
- Which files does it read or write?
- Which network addresses does it contact?
- Do tool calls match what you expected?
Our guide to sandboxing local MCP servers covers the options.
Record the decision
Write down the result so the next review is faster.
| Field | Your entry |
|---|---|
| Server, version, publisher | |
| Reviewer and date | |
| Steps passed / failed | |
| Tools allowed / blocked | |
| Scopes granted | |
| Conditions (sandbox, read-only, approvals) | |
| Next review date |
Add the server to your inventory. Our MCP security checklist covers the ongoing controls after install.
Next step
Reviewing many servers, or building your own? Our MCP readiness audit reviews the servers you already use. If a review shows you need a custom server instead, our MCP development team can build one with these controls in place.
Frequently asked questions
How long does an MCP server security review take?
A simple read-only server can take 30 minutes. A server that writes data or runs locally with broad access can take half a day, mostly in steps 2 and 9. Repeat reviews of a known server are quicker.
Do I need to review servers from big vendors?
Yes, but you can move faster. Steps 1 and 7 are usually easy for a major vendor. Still read the tools and scopes, because the risk depends on what you connect, not just who built it.
Can a security scanner replace this review?
Scanners help with steps 2 and 7, such as spotting suspicious tool descriptions. They cannot judge whether the access fits your business. See best MCP security tools for scanner options.
What if a server fails one step?
It depends on which. Failing steps 1, 3 or 5 usually means do not install. Failing step 6 may only mean you need tighter scopes or a read-only mode.
Should I re-review after updates?
Yes, at least for steps 2, 6 and 7. A server can change its tool descriptions after you approve it, which is called a rug pull. Pin versions so updates happen only when you choose.
