How to Audit Your MCP Servers Before Installing
Five checks, two minutes, one less thing to worry about. April 2026.
You found an MCP server on GitHub. It has a few hundred stars, a decent README, and it does what you need. You add it to your config and move on.
That is how most people install MCP servers today. No review, no audit, no idea what permissions the thing actually requests. I have done it too. It is fast and it mostly works. But "mostly" is doing a lot of heavy lifting when you are giving a server access to your filesystem, your browser, or your API keys.
This guide covers five things to check before you install any MCP server. You can do all five manually, or you can use audit.pyfio.com to automate them. Either way, it takes about two minutes.
Why bother auditing?
MCP servers run with the permissions you give them, but the protocol does not enforce boundaries. A server can declare that it only needs read access to your filesystem and then quietly write to it. There is no runtime sandbox by default. The only protection is knowing what you are installing before you install it.
When I scanned the 50 most popular MCP servers, the average score was 90.5 out of 100. That sounds good. But one of them had an eval() call in a Chrome extension, and Google's own CLI was in the bottom five for requesting broad filesystem and network access. Popularity is not a proxy for safety.
The five checks
Permissions and scope
Look at what the server requests access to. Does a Markdown formatting tool really need network access? Does a code search tool need to write files? The principle of least privilege applies here: a server should request only what it needs to function.
What to look for:
- Filesystem access (read, write, or both)
- Network access (HTTP requests, WebSocket connections)
- Environment variable access (API keys, tokens)
- Shell or process execution capabilities
If a server requests all four and its job is to format text, that is a red flag.
Code safety
Open the source code. Search for eval(), exec(), Function(), or any dynamic code execution. Look for HTTP requests that use user-controlled URLs (potential SSRF). Check if inputs are validated before being used in file paths or shell commands.
Red flags:
eval()ornew Function()anywhere in the codebase- User input concatenated into shell commands
- HTTP requests to URLs built from user-provided data
- File operations with unsanitized paths
Supply chain
Check the dependencies. A server with 200 npm packages in its dependency tree has a larger attack surface than one with 3. Look for a lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml). Missing lockfiles mean builds are not reproducible and dependency versions can shift between installs.
What to check:
- Number of production dependencies (fewer is better)
- Presence of a lockfile
- Any install scripts in
package.json(preinstall, postinstall) - Dependencies with suspicious names (typosquatting)
Transparency
Does the repo have a LICENSE file? Is there documentation explaining what the server does and what permissions it needs? A server with no license, no security documentation, and a vague README is not necessarily malicious, but it signals that the maintainer is not thinking about trust.
Maintenance signals
When was the last commit? Are issues being addressed? A server that was last updated 8 months ago and has 50 open issues might have unpatched vulnerabilities. Active maintenance is not a guarantee of safety, but abandoned projects are more likely to have known issues that nobody is fixing.
The automated way
If you do not want to do all five checks manually every time, audit.pyfio.com runs them automatically. Paste a GitHub URL, wait about 60 seconds, and get a scored report covering all five categories.
The free version gives you a full report for any public repo. It covers permissions, code safety (for JavaScript and TypeScript servers), supply chain analysis, transparency checks, and maintenance signals. Each category gets a score, and the overall result is a weighted average.
What to do if a server fails the audit
A low score does not automatically mean "do not use." It means "understand the risks before you decide." Some servers need broad permissions to do their job. A browser automation tool legitimately needs network access. A pentesting framework will have code patterns that look dangerous because they are supposed to be dangerous.
The question is whether the permissions and patterns match the stated purpose. If they do, and you trust the maintainer, proceed with awareness. If they do not, or if the code does things the documentation does not mention, find an alternative.
A two-minute habit
Before adding any MCP server to your config: run the audit. It takes less time than reading the README, and it tells you things the README will not mention. The MCP ecosystem is growing fast, and the tooling for evaluating trust is still catching up. Until there is a built-in permission enforcement layer, auditing is the best protection available.
Audit any MCP server for free
Paste a GitHub URL. Get a security report in about 60 seconds.
Try audit.pyfio.comGet MCP security updates
Tools, techniques, and security findings for AI agents. Weekly, no spam.