Loading…
This checklist shows how to vet an MCP server before an agent touches it, from provenance and reading a published grade honestly to auth, version pinning and credential scope.
A JWT is a signed bundle of JSON claims. Here is how to read one, why decoding is not verifying, and how to check for the classic JWT security flaws.
9 min read
Point-in-time MCP grades find risk; runtime firewalls enforce policy on tool calls. Andrax mcpgrade-1.4.0 vs Guard mcpgrade-2.0.0 — no score equating.
9 min read
Connecting an MCP server to an agent is a trust decision, not an install step. This is how to vet an MCP server before you make that decision: the seven checks I run, in order, and the signals that make me walk away.
For most servers it takes about ten minutes, and it covers more than inspection. Inspecting is reading what a server advertises; a grade is automated triage of that surface. Vetting is the decision you make with both, plus what a scanner can't see: who publishes it, how it authenticates, which version you'll run, and what credential it gets.
| Step | Check | Walk away if |
|---|---|---|
| 1 | Publisher and provenance | Name, repo, package and docs don't line up |
| 2 | Published grade and verdict | It's an F, or you're reading an N as a clean bill |
| 3 | Tool surface | Descriptions instruct the model instead of describing the tool |
| 4 | Capabilities vs the job | Write, exec or network tools the task doesn't need |
| 5 | Auth and transport | Public remote endpoint, non-public tools, no auth |
| 6 | Version pinning | Unpinned launch and no plan to re-vet |
| 7 | Credential scope | It wants your personal, long-lived, broad token |
Every later check assumes this is the server you think it is.
Namespace. Is the package under the vendor's own org, or a community fork? Forks aren't bad, but you're trusting a different publisher, not the vendor.
Lookalikes. Typosquats and near-miss names (a swapped letter, an extra "-mcp", "official" in a package name) are the cheapest attack in any registry. Copy the name from the vendor's docs, not a search result.
Cross-references. The repo should link the package, the package should link the repo, and the vendor docs should name both. For npm packages, read the install scripts before you run anything (npm view package-name scripts). A postinstall hook in a server that only answers JSON-RPC needs an explanation.
Our MCP server directory marks some entries as Official. The Filesystem MCP Server, for example, carries the Official label and is listed as Unscanned. Provenance and grade are separate facts, and you need both.
Most checklists skip this, and it's where I see people misread results.
On an Andrax graded page, read in this order: the letter or verdict, the score, the algorithm version, the number of checks run, the findings (sorted worst-first), the scan date, and whether the page says "Due for re-check". The scanner hub defines the letters: A/B is a clean surface, C/D carries real findings to review, and an F should gate the server until it's fixed. It also defines three verdicts that replace the letter when a number would mislead: T (invalid TLS), U (unreachable) and N (auth required).
Rubric fence: Andrax scanner grades are mcpgrade-1.4.0 (39 checks). SentinelAgent Guard's runtime is mcpgrade-2.0.0 (22 controls). Never equate the two scores.
Two real pages, both dated 2026-08-22 on their pages, show why the verdict matters more than the number: TrackRadar (N 98/100) and Salesforce SObject Reads (N 100/100) were graded only on their authentication surface, so neither number says anything about their tools.
An N with a high number. TrackRadar shows N 98/100 as of the 2026-08-22 scan, with 0 tools observed. The page says plainly that only its authentication surface was graded. All three findings are about auth: "Open dynamic client registration" (low), plus "PKCE S256 enforced" and "Client ID Metadata Documents supported" (both info).
An N with a perfect number. Salesforce SObject Reads shows N 100/100 as of the 2026-08-22 scan, again with 0 tools observed and one info finding, "PKCE S256 enforced". "Read-only" is the vendor's own description. The scanner couldn't verify it, because it couldn't see the tools without a token.
So N means auth required: only the authentication surface was graded, and the tool surface was not assessed. N 100 is not "safe". It tells you the front door is well built and nothing about what's behind it, which is why Steps 3 and 4 still apply once you authenticate.
A grade triages; it doesn't replace reading. Inspection means enumerating the server read-only (initialize, then the tools, resources and prompts lists) and reading every description, input schema and the server's instructions field. The full walkthrough is in how to inspect an MCP server.
What I look for:
notes, debug, feedback or URL field on a tool with no honest reason to send data anywhere.These are patterns, on purpose; you don't need a working payload to recognize one. Only inspect or scan servers you operate or are authorized to assess.
Sort the tools by verb: read, write, delete, execute, send, spend. Compare that with the job. A ticket reader shouldn't bring shell execution or arbitrary outbound requests. Disable what you don't need and allow-list tools where your client supports it.
Then look across servers. A read-only web fetcher is harmless alone. Put it in the same agent as a filesystem reader and anything that can post data out, and you've assembled private data, untrusted content and an exit: the lethal trifecta. Safety is a property of the combination, so vet the new server against the ones already connected.
Auth is where people tend to overstate the spec. The MCP authorization specification (revision 2026-07-28) makes authorization optional. When an HTTP-based server supports it, the spec builds on OAuth 2.1, and its security considerations require clients to implement PKCE, to use S256 when technically capable, and to refuse to proceed if the authorization server's metadata shows no PKCE support.
On client registration, the current revision says clients and authorization servers should support Client ID Metadata Documents (CIMD), and it marks Dynamic Client Registration (DCR) as deprecated, kept for backwards compatibility. That's why our scanner flags open, unauthenticated DCR and recommends CIMD, as on the TrackRadar page.
What I check on a remote server:
Local servers differ. A stdio server runs as a subprocess with your user's privileges, and the spec says stdio implementations should take credentials from the environment rather than follow the OAuth flow. So ask what that process can reach. A local server speaking HTTP should bind to 127.0.0.1, not 0.0.0.0; the Streamable HTTP transport section says so and requires Origin header validation.
Everything above describes one version. An unpinned launch such as npx -y some-server can pick up a newer release whenever the client starts it, so the server you vetted today isn't necessarily the one your agent talks to next week.
That gap is a rug pull: a server is approved while clean, and a later version changes a tool's description, schema or behavior. No exploit is needed; an update is enough.
The defense is boring, and it works:
Give the server its own credential: dedicated, revocable, short-lived and scoped to the job. Never your personal token or a long-lived admin key. The spec says authorization servers should issue short-lived access tokens, and that MCP servers must not pass through the token a client sent them.
Then decide what a snapshot is worth. For a low-privilege, read-only server in a lab, a fresh grade plus pinning may be enough. For a third-party server that updates often, or one that can write, delete, send or spend, you want something on the live path that checks each call. The full trade-off is in Guard vs grade-only MCP scanners.
A grade tells you what was wrong on the day it was scanned. If the server is third-party or updates often, put a gate on the live path too: SentinelAgent Guard's free tier runs all 22 controls on one server (see Free and Pro plans).
It's a start, not the decision. An A means no red flags in the surface the scanner saw on that date. It doesn't cover provenance, credential scope, or anything that changed since.
Auth required. Only the authentication surface was graded; the tool surface was not assessed. N 100 describes the auth setup, not the tools.
Yes. Treat every version as a new server: diff the tool definitions, re-scan, re-check the credential scope.
No. Official tells you who publishes it, not what the tools do or whether the grade is current. Some official entries in our directory haven't been scanned yet.
Not automatically. There's no network auth to get wrong, but a stdio server runs with your privileges and reaches whatever you can. The risk moves; it doesn't disappear.
Inspecting is reading the advertised surface. Vetting is the decision: inspection plus provenance, grade, auth, pinning and credential scope, with a clear walk-away rule.
Confirm the publisher, read the grade honestly (including what an N doesn't cover), read the tools, count the verbs, check auth, pin the version and scope the credential. Re-vet on every update: you approved a version, not a name.
Grade first on andraxpentester.in, then enforce Free/Pro on guard.sentinelreign.com. A grade finds risk; a gate enforces policy.
Andrax Pentester is not Android ANDRAX — we are a cybersecurity education site and MCP security grader at andraxpentester.in. Clear the name collision in one minute.
6 min read