A practical checklist for reviewing an MCP server before connecting email, databases, files, shell, cloud infrastructure, or remote tools.
MCP Security Review Checklist
Use this page before you install or approve an MCP server. The goal is not to block MCP adoption. The goal is to make the first connection small, observable, and reversible.
If you only have two minutes, start with the MCP Risk Calculator, copy the assessment, and then use this checklist for the review notes.
1. Source identity
| Check | Pass condition | Fail signal |
|---|---|---|
| Canonical source | Official registry, official docs, or a repo owned by the expected publisher | Random package with no clear owner |
| Package identity | Package name, repo, docs, and install command refer to the same project | Similar-looking package names or mismatched repository links |
| Maintainer trail | Recent commits or releases, issue responses, and readable docs | Abandoned repo, empty docs, or sudden publisher changes |
| Install path | Install command is understandable and pinned when possible | Curl-to-shell, hidden postinstall behavior, or unclear binaries |
Do not treat stars, directory listings, or social mentions as proof of safety. They are discovery signals, not permission evidence.
2. Permission and capability boundary
Classify what the server can do before thinking about whether the workflow is useful.
| Capability | First-test posture | Extra review required when |
|---|---|---|
| Read records | One test account, folder, database, or project | It can access full inboxes, customer data, source code, or regulated records |
| Write records | Disabled until read-only tests pass | It can send email, create tickets, update rows, or modify calendar events |
| Delete or destructive actions | Human approval outside the MCP call | It can delete files, records, pods, deployments, buckets, or user data |
| Filesystem | Single scratch folder | It can read home directories, source repos, secrets, dotfiles, or downloads |
| Shell or command execution | Tiny allowlist such as pwd, ls, cat | It can run package managers, network commands, scripts, or credential tools |
| Network access | Domain allowlist and request logging | It can send arbitrary outbound requests |
| Cloud or Kubernetes | Staging context, read-only role | It touches production resources or write-capable credentials |
3. Auth and secret handling
| Auth mode | Safer default | Watch for |
|---|---|---|
| No auth | Local-only test data | Remote server with no user-level boundary |
| API key | Dedicated low-scope token | Reused personal, admin, or production token |
| OAuth | Narrow read-only scopes | Broad workspace scopes, refresh tokens, or unclear token storage |
| Cloud IAM | Dedicated role and staging project | Owner, admin, wildcard, or production write permissions |
Secrets should stay out of docs, repos, screenshots, issue comments, and copied configs. A useful MCP guide must name which variables are sensitive.
4. Runtime and data path
Ask where the tool runs and where data can move.
| Runtime | Review questions |
|---|---|
| Local stdio | Which binary runs? Which files can it read? Can it execute subprocesses? Does it make network calls? |
| Remote HTTP/SSE | Who operates the endpoint? What data leaves the machine? Is auth user-scoped? Are logs retained? |
| Docker | Which volumes are mounted? Is the network open? Are credentials passed as env vars or files? |
| Cloud-hosted | Which tenant owns the infra? Can the operator inspect prompts, tool args, or outputs? |
Remote MCP can be useful, but the trust model is different. A remote server is not just an install command. It is a service you are sending tool context to.
5. First tool-call test
The first call should prove the connection works without exposing sensitive data or changing state.
Good first prompts:
List available tools and describe the lowest-risk read-only check.Show only metadata for the test dataset. Do not retrieve row contents.List namespaces and pod names in the staging context. Do not change anything.Avoid first prompts that ask for broad summaries, searches across private data, writes, deletes, or production troubleshooting.
6. Review note template
Copy this into a PR, issue, or internal review:
MCP server:
Source:
Install command:
Runtime: local stdio / remote HTTP / SSE / Docker / hosted
Auth mode:
Sensitive env vars or files:
Requested capabilities:
Data touched:
First-test scope:
Write/delete/exec enabled: yes/no
Rollback:
Risk tier:
Reviewer decision:7. Decision rule
Approve the first test only when all three are true:
- The server source is clear enough to explain to another developer.
- The credential scope is smaller than the real account or production system.
- The first tool call is read-only, observable, and reversible.
If any of those fail, do not argue about SEO, popularity, or convenience. Shrink the test.
Related tools
- MCP Risk Calculator
- Claude Desktop MCP Config Builder
- Add MCP Servers to Claude Desktop
- Best MCP Servers for Claude Desktop
Freshness: reviewed on May 17, 2026.