How to vet an MCP server before your agents load it

Every entry in a .mcp.json is third-party code — or a third-party endpoint — that runs with your agent’s privileges. Most teams review a new npm dependency more carefully than a new MCP server, even though the MCP server usually gets more access: filesystem roots, environment secrets, and a direct line into the model’s context.

Here is the checklist we use. It works for a one-off manual review; at the end, notes on what changes when you need to do this continuously across an org.

1. Confirm you have the official package

Typosquats thrive on install-command muscle memory. Before installing, find the server’s name from the vendor’s own documentation or repository — not from a search result or a pasted snippet — and compare character by character. One transposition is all it takes (the npm ecosystem spent a decade proving this).

2. Check the publisher, not just the package

• How old is the publishing account, and what else has it published?
• Does the package link to a real repository, and does that repository actually contain the code being published?
• Does the resolved version carry a provenance attestation tying the artifact to a source commit and build? An unsigned package isn’t automatically malicious — but combined with a young publisher and a familiar-looking name, it should stop the review.

3. Read the tool descriptions

Tool descriptions can become part of your agent’s context. Review the available descriptions, in full, before approving the server. You are looking for imperative instructions aimed at the model, references to files or credentials unrelated to the tool’s purpose, directives about other tools, and any variant of “do not tell the user”. This is the tool poisoning channel — the part of the package a code review never touches.

4. Check the install-time behavior

A package that runs scripts at install time deserves the same suspicion as any dependency with a postinstall hook. The malicious versions of well-known typosquats overwhelmingly do their damage before the tool is ever invoked.

5. Pin the version

latest re-resolves every launch — which means the server you reviewed is not necessarily the server your agent loads tomorrow. Pin an exact version. This single line of config makes package version changes explicit. It does not pin a remote server’s behavior, freeze every transitive dependency, or prove a selected version is safe.

6. Scope it to the minimum

If the server takes a filesystem root, point it at the project directory, not $HOME. If it takes API scopes, grant read-only unless writes are needed. Also enforce access using operating-system permissions or a sandbox: a configured root alone cannot contain a malicious server process. See the MCP security guidance.

7. Keep secrets out of the config

Use your harness’s supported environment or secret-reference syntax instead of storing credentials inline. RingZero’s managed catalog uses ${env:API_KEY} and translates it when syncing; native syntax differs between harnesses. Inline secrets end up in git history, in every checkout, and in every tool that reads the config — and they’re the first thing a scanner (or an attacker) finds.

8. For remote servers: verify the domain

An HTTP MCP server is an endpoint someone else operates. Confirm the URL is the vendor’s official MCP domain, not a lookalike, and route it through your org’s allowlist process so the next team doesn’t have to re-derive the answer.

9. Re-review on every change

A review is a snapshot. Version bumps, changed tool lists, and changed descriptions all invalidate it — remote servers can change without any version bump at all. Diff tool descriptions on change and treat unexpected differences as findings, not curiosities.

Doing this at org scale

The checklist is manageable for one server. The realistic situation is dozens of servers across dozens of repos, added by teams who never saw this list, changing underneath you. That’s an inventory-and-automation problem, not a diligence problem: something has to discover every configured server, run these checks continuously, and hand back the exact config change when one fails.

RingZero’s MCP security automates config discovery, local security checks, catalog sync, and policy evaluation in supported harnesses. Trust statuses summarize evaluated findings. Live description scanning, registry enrichment, and generated fix PRs through automated remediation are coming soon; those review steps remain manual today.