Installing an MCP server is letting third-party code into your AI agent's execution path. That code can read your files, query your databases, hit your APIs, and — if you wired it up wrong — leak credentials to the internet. This article is the checklist I wish I'd had when I installed my first dozen MCPs.
It's organized as eight things to verify before you click install, plus what to do when red flags appear.
1. Read the install command. Actually read it.
MCP servers install via commands like npx some-package or uvx some-tool. Every install is fetching a published package and executing it. The first quality bar is whether the package itself is legit:
- Is the package published from an official org (e.g.,
@modelcontextprotocol/server-filesystem) or a random user account? - How many versions has the package shipped? (Brand-new packages are higher risk than ones with 30+ versions and a year of history.)
- What's the GitHub repo? Is it active, or stale for 9 months?
- Does it match the company that supposedly published it? (A “Stripe MCP” from a personal GitHub account is suspicious.)
On CuratedMCP we publish the source repo and publisher identity for every server. Other marketplaces often hide this. If you can't trace a server back to a real, verifiable maintainer in 30 seconds, don't install it.
2. Classify the risk level
We use four risk tiers, and you should mentally apply something similar:
- 🟢 Read-only — fetches data, never modifies state. Safe in most agents. Example: a read-only Postgres MCP, weather API, search.
- 🟡 Read/Write — can modify your data. Acceptable with scope controls. Example: GitHub MCP that creates issues but doesn't delete repos.
- 🔴 Executes commands — runs shell, scripts, or arbitrary code. Use only with strong sandboxing. Example: a “run my tests” MCP.
- 🟣 Network egress — sends data to third-party services. Audit what's transmitted. Example: log forwarding, third-party APIs.
Every server you add increases your blast radius. If you have ten read-only servers and one execute-commands server, your effective security level is whatever the most permissive one is. Match the risk tier to the actual job.
3. Audit credential handling
MCP servers commonly need API keys (GitHub PAT, Stripe key, database password). Where do those credentials live? Three patterns, in decreasing safety:
- OAuth flow with short-lived tokens: best. The MCP server gets a token scoped to specific permissions, expiring in hours.
- Env vars from your local config: acceptable. Credentials live in your client config (e.g.,
claude_desktop_config.json), and the MCP reads them at startup. Risk: anyone with file access can read them. - API key in command line args: bad. Args show up in process listings and shell history. Avoid.
If a server documentation says “just paste your API key into the install command,” treat it as a yellow flag. Either find a better-implemented version, or wrap it with Sentinel to control what credentials it can access.
4. Verify the scope
Servers that ask for “full access” to a system are usually doing it because they were lazy, not because they need it. A well-designed MCP asks for the minimum scope possible:
- A GitHub MCP for code review needs
repo:read, notadmin:org. - A Postgres MCP for queries needs a read-only role, not
SUPERUSER. - A Stripe MCP for refunds needs the refund-specific scope, not full account access.
If the docs say “create a token with full access,” that's a red flag. Take five minutes to check whether the server actually needs it (by reading the source or asking the maintainer). Often it doesn't.
5. Check network egress
Some MCPs phone home — to telemetry servers, error reporting, “analytics.” That can be fine. It can also be a credential leak waiting to happen.
Quick check: run the server with network monitoring on (Little Snitch on macOS, a tcpdump filter on Linux), execute a few representative tool calls, and see what hostnames it contacts. If you see anything you didn't expect, dig in.
6. Read the dependency tree
Most MCP servers are 50 lines of business logic plus 800 lines of dependencies. That's where the actual risk lives.
Run npm audit or uv pip audit against the package. Look for:
- Known CVEs in dependencies (especially crypto, parsing, or networking libs)
- Abandoned packages (last update > 12 months ago)
- Unusually large dependency footprint (a 200-dep MCP is a big surface area)
- Suspicious typo-squatted package names (
require-sssh,colorss)
7. Use a runtime firewall
Static review only catches what's known at install time. A runtime firewall — like Sentinel — sits between your AI client and the MCP server, enforcing policies on every tool call:
- “GitHub MCP can create issues, but never delete repos.”
- “Filesystem MCP can read
~/projects, but never~/.ssh.” - “Any execute-commands tool needs manual approval.”
This is the single highest-leverage thing a serious MCP user can install. It makes the “random server I haven't fully audited” problem dramatically smaller.
8. Prefer Sovereign Certified servers
We can't review every MCP server in the wild. But every server in the CuratedMCP marketplace goes through a human security review covering all eight points above. Servers that pass get the Sovereign Certification badge.
That's not a guarantee — security never is — but it's a meaningful filter. Across the broader ecosystem, ~22% of submissions to CuratedMCP get rejected for quality or security issues. That's the number that doesn't show up on the open marketplaces.
What to do when you find a problem
If you find a security issue in an MCP server, the responsible thing is to contact the maintainer privately first. Most maintainers will fix it. If they don't respond in two weeks:
- Notify the marketplace where it's listed ([email protected] for ours).
- Publish a CVE if appropriate (npm and PyPI both have programs for this).
- Switch to a verified alternative.
The MCP ecosystem is too young to have mature disclosure norms. Building them is on us, the early users.
The 60-second version
If you don't have time to do all of the above for every install:
- Install only from verified marketplaces.
- Run MCP Auditor on your installed servers monthly.
- Use Sentinel as a runtime firewall.
- Re-audit any server before granting it production credentials.
That covers ~80% of the realistic risk. The rest takes time, but it's not optional for anything you'd put your real credentials in.