Vet an MCP server like any program you will run with a developer's privileges: confirm who maintains it, read the exact startup command, check the access it requests, run it in a sandbox first, and record the decision. Approve by version, not by name, and re-check on updates.
Why this deserves a checklist
An MCP server gives a coding agent new abilities, such as reading tickets, querying a database, or editing files. The MCP specification's security guidance describes local servers as binaries that run on the same machine as the client. It lists risks including arbitrary code execution, no visibility into what commands run, command obfuscation, data exfiltration, and data loss. Those risks apply to a convenient tool someone found in a directory last night.
Seven steps
- Identify the source. Who publishes it, where is the code, how long has it been maintained, and does the package name match the repository? Look for typosquats of well known servers.
- Read the startup command in full. The specification says clients should show the exact command without truncation. Do the same in review. Look for installs at launch, network calls, and access to home directory paths.
- Check what it can do. List the tools it exposes and mark each as read, write, or execute. A server that only needs to read tickets should not expose delete actions.
- Check the access it needs. Look at scopes and tokens. The guidance warns against omnibus scopes and recommends starting with minimal scopes and elevating on demand.
- Review dependencies. A server is software with its own dependency tree. Generate an SBOM and scan it for known problems before it goes on a laptop.
- Run it contained. Use a sandbox with limited file and network access first. Watch what it contacts.
- Record the decision. Write down the version approved, the reviewer, the scopes granted, and the review date.
Decision table
| Finding | Action |
|---|---|
| Unknown maintainer, no source, obfuscated start command | Reject |
| Known maintainer, broad scopes by default | Approve only with reduced scopes |
| Read-only tools, pinned version, clean dependency scan | Approve for a pilot group |
| Needs credentials for a production system | Escalate, use a dedicated narrow credential |
Remote servers are different
A remote server runs on someone else's machine, so you cannot sandbox it, but you can limit what you send. Check that it validates tokens issued to itself. The guidance forbids token passthrough, where a server accepts tokens not issued to it, because that bypasses controls and muddies audit trails. Also check whether it handles consent per client, which the guidance requires for proxy servers.
Keep an inventory
You cannot vet what you do not know exists. Developers add servers through config files in their editors and home directories. Collect them centrally, through a scan of repositories and managed devices where policy allows, and compare against the approved list. Our post on shadow MCP server detection covers discovery.
A worked example: vetting a ticket server
A team wants to connect a community built server that reads tickets from their tracker. The reviewer walks the seven steps.
| Step | Finding | Action |
|---|---|---|
| Source | Public repository, two maintainers, active for a year, package name matches | Continue |
| Startup command | Runs the package through a package runner, no extra shell commands | Continue, pin the version |
| Tools | Four tools: search, read, comment, close | Disable close, keep the others |
| Access | Requests a full account token | Replace with a token limited to read and comment on one project |
| Dependencies | SBOM shows forty packages, one with a known issue in a build tool | Update or document why it is not reachable |
| Contained run | Contacts only the tracker host and its own update server | Block the update server |
| Record | Version, scopes, owner, review date written down | Done |
The outcome is an approval with conditions, not a yes or no. The server is allowed in a pilot group with read and comment only, a pinned version, a narrow token, and an egress rule. Compare that with the usual path, where someone pastes a config snippet from a blog post and the server runs with a full account token.
What to re-check on updates
Approval attaches to a version. When the server updates, quickly review the diff of the startup command, the tool list, and the requested scopes. A new tool or broader scope should trigger a fresh review. Pinning versions prevents silent upgrades, and an update calendar prevents falling far behind.
Handling servers you cannot read
Some servers are closed or hosted. In that case you cannot review the code, so lean on what you can control: the token you give it, the data you let it see, and the logs you keep. The MCP guidance notes that servers should not accept tokens that were not issued to them, and it asks proxy servers to obtain consent per client. Ask the operator how they handle both. If you cannot get clear answers, treat the server as untrusted and give it only data you would be comfortable losing.
Roles
| Role | Responsibility |
|---|---|
| Requester | Explains the need and the minimum tools |
| Engineering owner | Owns the server in production use |
| Security reviewer | Runs the steps and signs off on scopes |
| Platform team | Maintains the approved list and sandbox image |
Keep the approved list in version control so changes are reviewed like code, and publish it where developers look.
A small habit that helps
Before approving, ask whether a built in capability or an existing integration could do the job. Every server you do not run is one you do not need to vet.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the setup steps and notice which choices change what a connected agent is allowed to do.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan. Safeguard also offers an MCP Guardrail for governing which servers agents may use.
Quick check
Is a popular MCP server automatically safe?
No. Popularity helps you find problems faster, but you still review the command, scopes, and dependencies, and you pin the version.
Who should approve a new server?
A named owner in engineering plus a security reviewer for anything that writes data or holds credentials.
How often should approved servers be reviewed?
On every version change that touches the startup command, tools, or scopes, and at least once a quarter for the rest.
Sources
Last reviewed: 19 October 2026.
