Evaluate an MCP server before you install it

Four things to read, in this order

You can tell a good deal about whether an MCP server is safe to run in about twenty minutes, without running it. Read the configuration block in its README to see which secrets it asks for. Read its tool list to see what it can do with them. Read the code that handles the riskiest tool. Then look at who maintains it and when it last changed. None of this proves a server is safe, but each step rules things out cheaply.

The order matters because each step tells you where to look in the next. The credential tells you what is at stake, the tools tell you how it could be spent, and the code tells you whether the tools do what their names say.

Start with the configuration block

Almost every server README prints a block of configuration for the client, naming the command to start it and the environment variables it expects. Those variables are the most honest part of the document. A server that wants a variable ending in TOKEN or SECRET is asking for a key to something, and the name usually says what.

Write the list down and ask, for each one, what the narrowest version of that key would be. A read-only token for one project is a very different install from an account-wide token with write access. If the README does not say which permissions the key needs, that is a finding in itself, and a reason to test with a deliberately limited key first.

The MCP server directory does this first pass for you on every row: the credential column is read from that same configuration block in the server's own repository, with the obvious placeholders such as YOUR_TOKEN removed. Treat it as a starting list rather than a complete one, because a server can ask for access in ways a README variable does not show.

Read the tool list as a list of permissions

Each tool is something the model may decide to do on its own once the server is connected. Read the names and descriptions with that in mind. A server described as a search helper that also exposes a delete tool is a server that can delete. A tool that takes a free-form query string and passes it to a database is a tool that can run any query the credential allows.

Look for the gap between the purpose in the first line of the README and the full set of tools further down. Small, single-purpose servers are easier to reason about. A server that wraps an entire API, every endpoint as a tool, gives the model the whole API, and the credential decides how much of that is real.

Open the code behind the riskiest tool

You do not need to read the whole repository. Find the handler for the tool that writes, deletes or sends, and read that. Check that it does what the description says and nothing else: that a tool called read does not also write, that a file tool stays inside the folder it claims to, that nothing posts data to an address you did not configure.

Then check what the install command actually runs. A command that fetches the latest version of a package every time it starts will run whatever was published most recently, which may not be the code you read. Pinning a version you have looked at is a small step that closes that gap.

Maintenance, licence and copies

A server nobody has pushed to in a long time may still work, and may be exactly what you want. It is a different risk from one shipped last week, though, because the protocol and the APIs it wraps have moved on. The directory lists stale and abandoned servers rather than hiding them, and marks the difference, so you can see which you are about to install.

Check for a licence. A repository without one is not yours to use, whatever it does. Check too whether the server is an unchanged copy of a starter template, which the directory counts separately so its size means something. A copy is not dangerous on that account, but it tells you nobody has made it do anything specific yet.

Stars tell you how many people noticed a repository. They are the only popularity signal the directory holds, and it orders by them while saying plainly that they are not a measure of quality. A highly starred server with a token that can write to production is still a server with that token.

A worked pass over one imaginary server

Say a README describes a server that helps an assistant answer questions about a project's documentation. The configuration block asks for a code host token and a path to a folder. That already says more than the description: the server reaches a code host, and it reads files from disk.

The tool list shows a search tool, a read tool and, near the bottom, a tool that opens a pull request with suggested edits. So the server can write to the code host as well as read it. That is a reasonable feature for a documentation helper, and it also means the token needs write scope, which the README does not mention.

The handler for the pull request tool takes a branch name and file contents from the model and sends them on unchanged. Nothing restricts which repository it targets beyond what the token allows. The fix for the install is a token limited to the one documentation repository, and a decision about whether the write tool is wanted at all. Twenty minutes of reading turned a vague description into a specific, narrow setup. The general rules for how the directory reads these facts are on how our data is gathered.