How to verify an MCP server yourself

Everything below is a statement about one published version, so choose it first. The version the registry serves as latest today can be a different one tomorrow, and a check of a moving target checks nothing. The commands assume macOS or Linux with Node installed; anything in angle brackets is yours to fill in.

npm pack, given a name and a version from the registry, fetches that version's published tarball into npm's cache and copies it into the current folder. It does not install it. The scripts npm lists for pack, prepack, prepare and postpack, belong to packing a folder, and install scripts belong to npm install. Add --ignore-scripts anyway: the pack documentation lists it, and it turns a reasonable expectation into a stated one.

The registry records an integrity string for every version: sha512, a hyphen, then the base64 SHA-512 digest of the tarball, in the Standard Subresource Integrity form npm's own lockfile uses. Compute the same digest of the file npm pack wrote, which is the name on its last line of output, and compare the two character for character.

A match means you hold the bytes npm serves for that version, and it is the same form of digest this site records beside its npm scans. It does not say who built those bytes or from which source; that is what a signed provenance attestation adds, where a package publishes one.

An npm tarball keeps everything under a folder called package. Unpacking it with tar writes files and runs nothing.

Open package/package.json. Under scripts, preinstall, install and postinstall are what npm runs when anybody installs this, before a single tool is called; npm's documentation lists them in that order. A binding.gyp at the root, with no install or preinstall script of its own, means npm compiles native code on install, and that is code running too.

Then read bin, which names the command npx runs, and main or exports, which is what another program loads when it imports the package. Those files are where the next steps look.

An MCP server describes each of its tools to the model, and the model reads those descriptions as instructions. The person running the agent never sees them. That is where tool poisoning lives: a sentence telling the model to read a key file, to keep a step from the user, or to use this tool in place of another one.

Most servers write their descriptions as string literals, so a search finds them: server.tool and registerTool calls, and description fields. Open each match and read the whole description, including any parts joined with a plus sign on the lines below it.

Read them against pattern set 1.0, the rules this site runs. Each rule shows a sentence it catches and the honest sentence nearest to it that it leaves alone, which is exactly the difference you are reading for. The second and third searches look for what a reader cannot see: characters that do not render, and the escape sequences that write them.

If the first search finds nothing, you have not read the descriptions: minified code and descriptions built at run time hide from a text search. Write that down as not checked. The complete answer comes from asking a running server for its tool list, which means running it.

Several issuers give their keys a fixed prefix, which makes a real key findable by its shape: AWS access key IDs begin AKIA, GitHub tokens begin ghp_, gho_, ghu_, ghs_, ghr_ or github_pat_, Stripe live secret keys begin sk_live_, and a private key in a file begins with a BEGIN PRIVATE KEY line.

Most matches are not leaks. Test values, documentation examples and other scanners' detection rules all have the shape. Read each one where it sits before calling it anything.

A real one belongs to everybody who has installed that version, and removing it from the next release does not remove it from the ones already published. Tell the maker privately so they can revoke it. Do not post the value, the file or the line anywhere public, an issue included.

OSV, the open vulnerability database, answers for an exact version of an npm package. Ask it about the package itself first.

Most of what runs is somebody else's code, so ask about the dependency tree as well. In a fresh folder, npm can resolve the tree into a lockfile without installing anything, and npm audit reads the lockfile.

An advisory says a version has a published defect. It does not say whether this server ever reaches the vulnerable code, which is the question to ask next.

The license field in package.json should be an SPDX identifier such as MIT or Apache-2.0, and the tarball should carry the licence text itself. A field that says SEE LICENSE IN a file means that file has to be in the tarball, so check that it is.

No licence at all means nobody has been given permission to use, copy or change the code, however public it is.

Every address written in the code is a place it might send something. List them, then compare the list with what the README or the listing says the server contacts. An unexplained host is a question for the maker, and so is an expected one that is missing.

Then find the calls that make requests, and read what goes into them: which arguments, which files, which environment variables.

A host written in the code is not proof the server calls it, and a host missing from the code is not proof it does not, because an address can be built at run time. This reads what was written down, and says so.

A server you connect to over HTTP runs code you cannot read, so the check that remains is whether it lets strangers in. The protocol's authorization rules say a server that requires authorization answers a request with no token with 401 Unauthorized and a WWW-Authenticate header naming where its protected resource metadata lives.

Send one initialize request with no credentials, as a client would, and read the status and the headers. Then fetch the metadata address the header names, and check that it names an authorization server.

If it answers 200 and goes on to list its tools for anybody, it is open. That can be right for a server that only reads public data, and it is never right for one that can act on an account. Do not call a tool to find out more, and send requests only to the endpoint the maker publishes.

None of the above ran the server, so none of it says how the server behaves: what it reads when a tool is called, what it sends, what it does with a URL it is handed. The SSRF guide covers the one behavioural test worth running yourself, locally, before anything real is connected.

For a remote server, the code you read, if there was any, is not proof of what the endpoint runs. And a repository's history, where a deleted key still lives, is not in the tarball at all.

Keep that list beside the result. A check that says what it did not cover can be relied on for what it did.