Trusted MCP Servers: How to Verify Before You Install

An MCP server runs on your machine. It has access to your filesystem, your network, and whatever credentials you pass to it. When you install an MCP server, you are granting a piece of third-party code significant access to your development environment — and by extension, to your data, your API keys, and your clients' information.

Most developers do not think about this. They find an MCP server on GitHub, run npx, and move on. The server works, so it must be fine. Right?

Not necessarily. The MCP ecosystem is growing fast, and with that growth comes risk. Malicious servers, abandoned projects with unpatched vulnerabilities, and well-intentioned but poorly secured tools all exist in the wild. The question is not whether you will encounter an unsafe MCP server — it is whether you will recognize one before you install it.

This guide gives you a practical, repeatable process for evaluating MCP server trustworthiness before installation. It includes a 7-point security checklist, red flags that should stop you immediately, and tools for automated verification.

Why Trust Matters More for MCP Servers

MCP servers are not like regular npm packages or Python libraries. They have unique properties that amplify the consequences of installing an untrustworthy one:

• They run as persistent processes — unlike a library function that executes and returns, an MCP server stays running for the duration of your session, continuously listening and responding
• They receive your data — when your AI assistant calls an MCP tool, the input (which may include code, credentials, or sensitive business data) is sent to the server process
• They can make network requests — a malicious server can exfiltrate data to an external endpoint without any visible indication
• They run with your permissions — the server process inherits the permissions of the parent process (your IDE or terminal), including filesystem access and environment variables
• They are opaque at runtime — once running, an MCP server's internal behavior is difficult to observe without specialized tools

The combination of persistent execution, data access, network capability, and runtime opacity makes MCP servers a high-value target for supply chain attacks. The MCP server path traversal vulnerabilities documented earlier this year demonstrated exactly how these attack vectors work in practice.

Red Flags: When to Walk Away Immediately

Before going through the full checklist, here are the red flags that should stop you from installing an MCP server immediately:

No Source Code Available

If the MCP server is distributed as a compiled binary or obfuscated bundle with no source repository, do not install it. Period. You cannot verify what code runs on your machine if you cannot read it.

Requests Unnecessary Permissions

A database query server should not need filesystem write access. A file search server should not need network access. If the server's configuration requires permissions that do not match its stated purpose, treat it as suspicious.

Asks for Broad Credentials

An MCP server that asks for your root database password, admin API token, or cloud provider credentials with full access is a red flag. Legitimate servers request minimal, scoped credentials — a read-only database user, an API token with specific scopes, a limited access key.

Recently Created with No History

A GitHub repository created last week with a polished README but no commit history, no issues, no contributors, and no usage evidence should be treated with extreme caution. This is a common pattern for malicious packages that exploit trending keywords.

Name Squatting or Typosquatting

Watch for MCP server names that are slight misspellings of popular servers. @modelcontextprotocol/server-filesysem (note the typo) is not the same as @modelcontextprotocol/server-filesystem. This attack vector is well-documented in the npm ecosystem and is now appearing in MCP.

The 7-Point MCP Security Checklist

For every MCP server you consider installing, work through this checklist. A server that fails on more than one point should be rejected unless you have a compelling reason to accept the risk.

1. Source Code Review

What to check: Is the full source code available in a public repository? Can you read and understand what the server does?

How to check: Visit the repository. Look at the main server file. Trace the code path from tool definition to execution. Check for any network calls that are not part of the tool's stated functionality.

Pass criteria: Source code is publicly available, readable, and matches the server's stated purpose.

2. Dependency Audit

What to check: What dependencies does the server install? Are any of them known-malicious, unmaintained, or suspiciously named?

How to check: Review package.json or requirements.txt. Run npm audit or pip audit. Check each dependency's download count and last update date.

Pass criteria: All dependencies are well-known, actively maintained, and free of known vulnerabilities.

3. Permission Scope Analysis

What to check: What permissions does the server need? Do those permissions match its functionality?

How to check: Read the configuration requirements. If the server needs API keys, check what scopes those keys require. If it needs filesystem access, check what directories it accesses.

Pass criteria: Requested permissions are minimal and directly related to the server's stated purpose.

4. Network Behavior Analysis

What to check: Does the server make outbound network requests? If so, to what endpoints?

How to check: Review the source code for HTTP client usage (fetch, axios, httpx, requests). Check if outbound URLs are hardcoded, configurable, or dynamically constructed. For a runtime check, run the server with network monitoring enabled.

Pass criteria: All network requests are to expected endpoints (the API the server is designed to call). No unexpected outbound connections.

5. Author and Maintainer Verification

What to check: Who built this server? Do they have a track record? Are they a real person or organization?

How to check: Check the repository owner's GitHub profile. Look at their other repositories, contribution history, and account age. Check if the organization behind the server is legitimate.

Pass criteria: Author has a verifiable identity, a history of open-source contributions, and other maintained projects.

6. Community Signals

What to check: Is anyone else using this server? Are there issues, discussions, and contributions from the community?

How to check: Check GitHub stars, forks, and open/closed issues. But do not stop at stars. Stars can be purchased. Check for genuine issue discussions, pull requests from outside contributors, and mentions in developer communities. A server with 5,000 stars but zero issues and zero PRs is suspicious.

Pass criteria: Evidence of real usage — genuine issues, community contributions, and organic discussion.

7. Verification and Trust Score

What to check: Has the server been independently verified by a trusted third party?

How to check: Search for the server on AgentNode. If it is listed, check its trust score and verification tier. A Gold (90+) or Verified (70-89) score means it has passed sandbox testing including installation, import, smoke testing, and permission verification.

Pass criteria: Server has a Verified or Gold trust score on AgentNode, or you have personally completed all six checks above with passing results.

You can find trusted MCP servers on AgentNode where every listing includes a trust score breakdown, or compare MCP registries to see how different platforms approach server verification.

Why GitHub Stars Do Not Equal Trust

This point deserves its own section because it is one of the most dangerous assumptions developers make.

GitHub stars are a measure of interest, not safety. They tell you that people clicked a button. They do not tell you:

• Whether anyone audited the code
• Whether the server handles credentials safely
• Whether the dependencies are secure
• Whether the server has been tested in a sandboxed environment
• Whether the server's behavior matches its documentation

Worse, stars can be purchased in bulk. A malicious actor can create a repository, buy 2,000 stars for a few hundred dollars, and present a convincingly popular project. This has happened in the npm ecosystem repeatedly, and it is now happening in the MCP ecosystem.

Stars are a signal, but they are a weak signal. A server with 10,000 stars and zero verified trust score is less trustworthy than a server with 50 stars and a Gold verification tier.

Using AgentNode's Trust Scores

AgentNode provides an independent, automated trust assessment for MCP servers and agent tools. Here is what each tier means:

Gold (90-100)

The server has passed all verification stages: clean installation, successful import, passing smoke tests with generated inputs, passing publisher-provided tests, and consistent behavior across multiple runs. This is the highest assurance tier. Gold servers have been tested in an isolated sandbox with no network access, and their behavior matched their declared permissions.

Verified (70-89)

The server installs, imports, and runs successfully with minor gaps. Common reasons for a Verified (rather than Gold) score include: tests that require API credentials (which cannot be provided in the sandbox), minor inconsistencies in output format, or missing publisher-provided tests. A Verified server is still strongly trustworthy.

Partial (50-69)

The server installs and imports but has limited runtime verification. This typically means the server requires external services (API keys, databases, third-party endpoints) that cannot be replicated in the sandbox. The code passes static checks, but runtime behavior is only partially verified. Use with additional caution — manually verify the specific functionality you plan to use.

Unverified (Below 50)

Significant verification issues. The server may fail to install, have broken imports, crash during testing, or exhibit behavior inconsistent with its declared permissions. Do not use in production without a thorough manual audit.

For a deeper understanding of how these scores are calculated, see the guide on understanding verification trust scores.

Manual Verification: A Step-by-Step Walkthrough

If an MCP server is not on AgentNode, you can perform manual verification. Here is the process:

Step 1: Clone and Read

git clone https://github.com/author/mcp-server-example.git
cd mcp-server-example
# Read the main server file — understand what tools are defined
# Check for any network requests not related to stated functionality
# Look for filesystem operations outside declared scope

Step 2: Check Dependencies

# For Node.js servers
npm audit
npm ls --all  # Review the full dependency tree

# For Python servers
pip audit
pip show -f package-name  # Check installed files

Step 3: Run in Isolation

# Run the server with restricted network (Linux/Mac)
# Use a container or VM for maximum isolation
docker run --rm --network=none -v $(pwd):/app -w /app node:18 \
  npx @example/mcp-server

Step 4: Monitor Network Activity

# On macOS
sudo lsof -i -P | grep node

# On Linux
ss -tlnp | grep node

# Or use a network monitoring tool like mitmproxy

Step 5: Test With Benign Inputs

Call each tool with simple, non-sensitive inputs. Verify that the outputs are correct and that no unexpected side effects occur (file creation, network requests, environment variable access).

Verified vs. Unverified: The Risk Comparison

To make the stakes concrete, here is what can go wrong with unverified MCP servers:

Risk	Verified Server	Unverified Server
Data exfiltration	Tested in sandbox with no network; behavior audited	Unknown; could send your data anywhere
Credential theft	Permission declarations verified against behavior	Could read all environment variables and send them externally
Filesystem damage	Filesystem access tested and scoped	Could read, modify, or delete any file your user can access
Dependency attacks	Dependencies audited during verification	Transitive dependencies could include malicious code
Backdoor installation	Code behavior analyzed in sandbox	Could install persistent backdoors on your system
Cryptomining	Resource usage monitored during testing	Could consume CPU/GPU for cryptocurrency mining

The difference is not theoretical. The MCP ecosystem has already seen instances of servers that exfiltrate environment variables, install persistent processes, and make unauthorized network requests. For documented examples, see the analysis of best verified MCP servers for Claude, which contrasts verified options with known-risky alternatives.

Building a Trusted MCP Server Stack

Rather than evaluating servers one at a time, build a curated stack of trusted servers that covers your needs:

1. Start with official servers — the @modelcontextprotocol organization on npm publishes reference implementations. These are maintained by the MCP specification team and are the safest starting point.
2. Add verified servers from AgentNode — search the AgentNode catalog for MCP-compatible tools with Verified or Gold trust scores.
3. Evaluate community servers carefully — for servers not on AgentNode, apply the full 7-point checklist before installation.
4. Review your stack regularly — check for updates, new vulnerabilities, and changes in maintainer activity at least monthly.
5. Use project-level configuration — keep your MCP server configuration in .cursor/mcp.json or .claude/config.json per project, so different projects use different (and minimal) server sets.

What Comes Next for MCP Security

The MCP ecosystem is young, and its security infrastructure is still evolving. Several improvements are on the horizon:

• Permission enforcement — runtime sandboxing that restricts servers to their declared permissions, rather than relying on declarations alone
• Signed packages — cryptographic signatures that verify a server was published by its claimed author
• Behavioral monitoring — real-time analysis of server behavior during operation, with alerts for anomalous activity
• Standardized security metadata — a common format for declaring security properties that all MCP clients can read and enforce

Until these features are widely available, the burden of verification falls on you — the developer. The 7-point checklist in this guide is your best defense. Use it every time you install an MCP server, and encourage your team to do the same.