How to Vet an MCP Server Before You Install It

Before you add an MCP server, confirm who publishes it, read what it runs, list its tools in an isolated environment, and decide what access it really needs. A listing in a registry is not a safety check. If you cannot find out who runs a server or what it does, do not install it.

Our guide to MCP server security covers reviewing servers you already have. This one comes earlier, at the moment someone says "just add this server". It is short enough to use each time.

Start with whether you need it

Each server adds tools, tokens and code you must keep track of. Ask three things first:

• What task will this server do for you?
• Could an official tool, or a tool you already use, do the same job?
• What is the worst thing it could do with the access it wants?

If the task is occasional, a one-off script might serve you better than a server that stays connected.

Step 1: Confirm who publishes it

1. Find the server's home page and source repository.
2. For a service like GitHub or Slack, go to that company's own docs and follow their link. Do not start from a search result.
3. Compare the package name letter by letter, since near-matches are a common trick.
4. Check that the package links back to the repository, and that the repository links to the package.
5. Look at the publisher's history. A brand new account with one package deserves more care.

The official MCP Registry helps with part of this. It ties a server's name to a verified GitHub account or domain, so only that owner can publish under that name. But it says security scanning of server code is left to package registries and downstream marketplaces. The registry is also in preview. Treat a listing as proof of who published something, not proof that it is safe.

Marketplaces and directories vary, so check what each one actually reviews. Stars and download counts can be useful signals, but they can be inflated.

Step 2: Read what it would run

For a local server, the install line is a command that runs on your machine.

• Read the exact command in the instructions, including all arguments.
• Be wary of curl piped into a shell, sudo, and encoded text.
• Look at install scripts in the package, such as postinstall in an npm package.
• Skim the code that defines the tools, and check for network calls to places you would not expect.
• Look for recent ownership changes, and big releases with little explanation.

You do not need to read every line. You are looking for anything that does not match the stated purpose. If a simple notes server wants to read your SSH folder or call an unknown domain, stop.

For a remote server, you cannot read the code. Your checks move to the operator: who runs it, what their privacy terms say, and what data they keep.

Step 3: Inspect it in isolation

Do this in a container or virtual machine with no personal files, no real tokens and limited network access. Running a local server means running its code, and listing its tools starts it too.

1. Set up the isolated environment.
2. Use the MCP Inspector, the official testing tool, to start the server and list its tools. It runs with npx @modelcontextprotocol/inspector.
3. Use a current version. Version 2.12.0 fixed security issues in earlier 2.x releases, and 2.13.0 gives advice on Node.js versions.
4. Read every tool name and description. The MCP specification says tool descriptions should be treated as untrusted unless they come from a server you trust.
5. Look for hidden instructions, such as text telling the AI to read other files, keep something secret from you, or call a different tool first.
6. Try each tool with harmless test data, and watch what it does.
7. Watch network traffic if you can, and note any host you did not expect.

Step 4: Decide what access it gets

Write down the access you will grant, before you add any token.

• Scopes. Use read-only where you can. The MCP guidance warns against wildcard scopes and bundling unrelated rights.
• Tokens. Create a new token just for this server, with an expiry date. Do not reuse a personal token.
• Paths. Give it one project folder at most, not your home folder.
• Data mix. Avoid one session that combines private data, untrusted content and a way to send data out.
• Tool approvals. Keep confirmation on for anything that writes, deletes or sends.

For a remote server, read the consent screen in full before you approve it. Check that the domain matches what you expect, and that the requested access fits the task.

Step 5: Install it with limits

1. Pin an exact version, such as some-package@1.2.3, not the latest one.
2. Add it to one project at first, not to your global config.
3. Keep tokens out of the config file. Use your client's secure inputs or a secrets manager.
4. Restart your app, and confirm the tool list matches what you reviewed.
5. Give it a low-stakes task first.
6. Write down why you added it, who owns it and when to review it.

Step 6: Plan for change

A server you reviewed today can change tomorrow. An update can add tools or rewrite descriptions, and a maintainer's account can be taken over.

• Read release notes before you move to a new pinned version.
• Compare tool lists after an update.
• Remove servers you have not used in a while.
• Revoke tokens as soon as you remove a server.

Prycheck can list the MCP configs on your computer, so you can see what is set up, though it does not judge whether a server is safe.

Frequently asked questions

Is a server safe if it is in the official MCP Registry?

Not by itself. The registry verifies who controls a namespace, and leaves code scanning to others. Use it to confirm the publisher, then do your own checks.

Is a remote server safer than a local one?

It carries different risks. A remote server cannot run code directly on your machine, but it does receive your data and may hold tokens. Choose based on who runs it and what access it needs.

How long does this check take?

A well-known server from a company you already use may take a few minutes. An unknown server with broad access deserves longer, or a decision not to use it.