To vet an MCP server before installing, confirm the publisher matches the vendor, read every tool and its description, check whether it is maintained and has patched past CVEs, see how it handles credentials, and prefer an official remote server over a community package. Run it sandboxed and pinned to a version the first time.
Key takeaways
- Popularity is not evidence of safety. Check who published it, not how many people installed it.
- Read tool descriptions yourself. Instructions aimed at the model are a red flag.
- A server that needs more access than its job requires is a reason to stop.
- Pin the version, because a clean release can be followed by a bad one.
- Use the smallest credentials that work.
What should you check first?
Check whether the vendor offers an official remote MCP server. Remote servers from the vendor typically use OAuth, which avoids trusting a community package and storing long lived tokens on your machine. If one exists, use it and skip the rest of the community options.
How do you confirm the publisher is real?
Confirm that the GitHub organization or npm publisher actually belongs to the company whose product the server connects to. Look for a link from the vendor's own documentation to the repository, not the other way round.
This step matters because impersonation is a real pattern. A checklist from Mailtrap lists a fake npm package called postmark-mcp that worked normally for about 15 releases and then added code that blind copied every sent email to an attacker. It also lists a cloned Oura Ring integration made with fake GitHub accounts that deployed an infostealer.
What tools and permissions does the server expose?
Each tool should have one clear, legitimate purpose. A documentation server should not need filesystem access, and a read-only search tool should not modify data. List the tools, then ask what happens if the model uses each one in the worst way.
Do the tool descriptions contain instructions?
Read them before the model does. A description should explain capabilities, parameters and return values. Any text that tries to steer the model's behaviour is a red flag and can be tool poisoning.
Is it maintained, and has it had CVEs?
Check that past vulnerabilities were patched and the project is still active. How quickly issues get fixed matters more than having a clean record. Mailtrap cites CVE-2025-6514 in mcp-remote, where improperly validated redirect URLs let a malicious server run shell commands, and the package had over 437,000 downloads at disclosure. Downloads did not protect anyone.
Also run the server's package.json or requirements.txt through the free in-browser dependency scan at gold.safeguard.sh/scan. It covers up to 100 dependencies, needs no login, and the file stays on your machine.
How does it store and use credentials?
Prefer OAuth. If the server needs a long lived API token, accept the local storage risk only if the token is handled well, and issue the narrowest token you can. Claude Code's documentation suggests a fine grained GitHub token limited to specific repositories and a read-only database user.
How should you run it the first time?
Run it sandboxed. The MCP specification warns that local servers run with the same privileges as the client and that a startup command can hide data theft. Look at the exact command in the config, with all arguments, before you approve it. Keep tool approvals on, as Cursor does by default for MCP tools.
Vetting checklist
- Official remote server checked first
- Publisher matches the vendor, confirmed from the vendor's docs
- Every tool listed, with a clear purpose
- Tool descriptions read, no steering text
- Maintenance and CVE history reviewed
- Dependencies scanned
- Credentials minimal, in environment variables
- Version pinned, first run sandboxed
Frequently asked questions
Is an MCP server in a directory safe?
Not automatically. Claude Code's documentation says Anthropic reviews connectors against listing criteria but does not security-audit or manage any MCP server.
Do I need to read the source code?
For critical integrations, yes. Cursor's documentation says to audit the code for those. For low risk tools, publisher, tools and permissions are the minimum.
What is tool poisoning?
It is hidden instructions in a tool's description or output that steer the model into actions you did not ask for.
Can a server be safe in one version and unsafe in the next?
Yes. The postmark-mcp case added its malicious code after many clean releases, which is why you pin versions and review updates.
Sources
- Mailtrap, MCP server vetting checklist: https://mailtrap.io/blog/mcp-server-security/
- MCP specification, security best practices: https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
- Cursor MCP documentation: https://cursor.com/docs/mcp
- Claude Code MCP documentation: https://code.claude.com/docs/en/mcp
- Safeguard Gold dependency scan: https://gold.safeguard.sh/scan
Last reviewed: 19 October 2026.
