How to vet an MCP server before you connect it to your agents

To vet an MCP server before you connect it to an agent, run five checks, in this order: confirm it declares a real license, confirm someone is still maintaining it, confirm it ships versioned releases with a readable changelog, confirm it requires auth and asks for no more access than it needs (least privilege), and confirm who actually publishes it. Most of the five take under a minute each, and none require reading source code line by line. They're the same five signals — maintenance, adoption, transparency, security and provenance — that make up a Vouchity Trust Score, so you can run this checklist by hand every time, or look the server up once and let the score do it for you. Either way, treat it as the floor for mcp best practices, not an optional extra.

1. License — the one-second check most people skip

Open the repo root and look for a LICENSEfile, or check the license field on the package registry page. No license doesn't mean "free to use" by default — under copyright law it means the opposite: nobody but the author has a clear legal right to use, modify or redistribute the code, whatever the README implies. The Open Source Initiative, which maintains the reference list of approved licenses, puts it plainly:

Open source licenses are licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared. opensource.org/licenses

MIT and Apache-2.0 are the two you'll see most often on well-run MCP servers, and either one is a clean green flag. A missing license is far more common than most people assume: across the 320 servers Vouchity tracks, 176 (55%) publish no license at all.

2. Maintenance — is anyone still home?

Don't check when the repo was created — check when it last changed. On GitHub, open the Releases tab or the commit history directly; on npm, run npm view <package> time.modified from a terminal to get the exact last-publish date without opening a browser. A server with no meaningful activity in over a year is unlikely to get a fix if a dependency turns up a vulnerability or the protocol itself changes underneath it. Two states are hard stops rather than yellow flags: a repository marked archived on GitHub, and a package explicitly marked deprecated on its registry. Among the servers we track, 2 have archived repositories and 3 carry a deprecated status directly in the official MCP registry — small numbers, but worth catching before you install one of them by accident.

Adoption is a weaker but still useful companion signal here. GitHub stars and weekly npm downloads don't prove quality, but a total absence of either tells you something real: you'd be among the first people to hit a bug the hard way, with nobody ahead of you who already reported it. Low adoption isn't disqualifying for a new or deliberately niche server — it just means the other checks in this list carry more weight, because there's no crowd of prior users to have already caught a problem.

3. Versioning and changelog — can you pin a known-good release?

A server that only ever ships off a moving main branch gives you nothing to pin against: the version you install today can be silently different from the one a teammate installs tomorrow, and if something breaks you have no earlier known-good point to roll back to. Check for tagged releases that follow real semantic versioning (a jump from 1.4.0 to 2.0.0 should mean something changed in a breaking way, not just that the author felt like it), and look for a CHANGELOG.md or a populated Releases page that says what changed between versions, not just that a new one exists. A project stuck on 0.xforever isn't automatically untrustworthy — pre-1.0 is a legitimate signal that the author considers the interface still unstable — but it does mean you should re-check the tool schema every time you bump the version, rather than assuming compatibility.

4. Security — auth, least privilege, and what the tools can actually reach

Read the tool list before you connect anything, not after. Three concrete things to check:

• Auth, for anything remote. If the server runs over HTTP rather than as a local stdio subprocess, it should require authentication — otherwise anyone who finds the endpoint can call its tools. The MCP specification itself is explicit that transport-level authorization is how this is meant to work for HTTP-based servers, and that stdio servers should instead pull credentials from the local environment rather than skip the concept entirely.
• Least privilege in the tool scopes. A tool called search_files can be scoped to one directory, or it can silently reach your entire home folder; a tool called send_emailcan require explicit confirmation, or fire immediately with no check. None of this shows up in the tool's name — check what host, filesystem or API scope each tool actually requests, and treat a request for broader access than the server's stated purpose as a real red flag, not a rounding error.
• Instruction-shaped text in tool output. Read tool descriptions and a sample of real output for anything that reads like an instruction aimed at the model rather than a description aimed at you — a classic prompt-injection pattern, where a tool result quietly tells the model to take some further action.

This maps directly onto a named risk in OWASP's Top 10 for LLM Applications, LLM06: Excessive Agency, which OWASP breaks into excessive functionality, excessive permissions and excessive autonomy:

Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction. OWASP LLM06: Excessive Agency

OWASP's stated fix is the same one that matters here: limit what an agent is allowed to call to the minimum necessary, rather than granting broad access up front and hoping it's never misused. A large, sprawling tool surface is itself a mild risk factor independent of any single tool — more surface, more that can go wrong, more for you to actually read. For more on this pattern specifically, see MCP server security in 2026 and what prompt injection looks like in practice.

5. Provenance and deprecation policy — who stands behind it, and what happens when they stop?

Prefer a server published under a real, verifiable identity — a reverse-DNS namespace tied to an actual domain or organization (io.github.acme/..., com.company/...) — over an anonymous handle with no way to confirm who's behind it. An official or reference server maintained by the protocol authors or the tool vendor itself, or one carrying active status in the official MCP registry, is a stronger signal than a hobby fork nobody has looked at since it was first published.

Then check for a deprecation policy— not because most authors have a formal one, but because the absence of any signal is itself informative. A README line as simple as "this project is maintained on a best-effort basis" or "deprecated, use X instead" tells you exactly how much to rely on it. A project that goes quiet with no explanation, still listed as active, is the pattern to watch for: it looks alive because the last commit wasn't that long ago, right up until the point where it very much isn't. The official registry's own lifecycle field — active, deprecated or deleted— is worth checking directly for this reason rather than trusting the repo's README alone, since a publisher can mark a listing deprecated in the registry even after archiving the repo elsewhere.

The checklist, scannable

Putting it together

Doing all five checks by hand for every server you try doesn't scale past the first few, which is why Vouchity computes them for every server in the registry and combines them into one 0–100 Trust Score with a letter grade — see exactly how, weight by weight, in our methodology. Look a server up in the registry— each server's page shows its full signal breakdown, including the ones that failed — browse by category, or scan the highest-scoring servers on the trust leaderboard. Want the servers currently carrying the most risk flags instead? Start with the flagged list. And if you're building an agent that needs to make this call itself, have it query Vouchity's own hosted MCP endpoint with get_trust_score or check_server_safety before it ever calls the tool in question.

A few things a high score can't tell you

No score replaces judgment. A well-maintained, well-licensed, properly authenticated server can still be the wrong fit for your use case, ask for more scope than your workflow actually needs, or simply not do what you want. And the reverse is also true — a low-adoption server built by a first-time publisher can still be exactly right for a narrow job, provided you've actually read what it does rather than skipped straight to the score. Treat the five checks above, and the score that summarizes them, as the floor for "safe to try," not the ceiling for "guaranteed to be right for you." If you're publishing a server yourself rather than just installing one, the same five checks apply in reverse — see building an MCP server people will actually trust for the author's-side version of this checklist.