How To Audit An MCP Server Before You Install It

Installing an MCP server gives an AI agent new abilities, and new ways to go wrong. A server can read files, query databases, send messages or run commands, and its tool descriptions are text the model trusts. Most servers are fine. Some are abandoned, over-privileged or poorly built, and a few are malicious. This guide gives a practical, step-by-step audit you can run before any MCP server reaches a developer laptop or a production agent.

If you are new to the protocol, start with our explainer on what MCP is.

Step 1: Confirm Who Publishes It

The single most useful check is the publisher. A server run by the company that owns the underlying system, such as GitHub’s server for GitHub or Stripe’s for Stripe, is almost always safer than a community wrapper around the same API.

• Look the server up in the official MCP Registry, where names are tied to a verified GitHub account or domain.
• Check curated directories that label official servers; our list of MCP directories and registries explains which ones verify publishers.
• Be wary of look-alike names that imitate a well-known vendor.

Step 2: Check Maintenance And Reputation

• When was the last release, and are issues and security reports answered?
• Does it support the current MCP specification, including the July 2026 release?
• How many people use it, and do reputable sources reference it?
• Is there a security policy or a way to report vulnerabilities?

An unmaintained server will not get fixes when new attack techniques appear.

Step 3: Read The Tool Descriptions

Tool descriptions are instructions the model reads, so they are a prime place to hide prompt injection. List every tool the server exposes and read each description and parameter schema in full.

• Look for instructions aimed at the model, such as telling it to read other files, include hidden data or contact another address.
• Check whether descriptions can change at runtime. Pin a version so a server cannot quietly update what it tells your agent.
• Note any tool that seems unrelated to the server’s stated purpose.

Our guide on what prompt injection is explains why this matters.

Step 4: Map What Each Tool Can Do

Sort tools into read, write and destructive actions. A documentation server should only read. A server that can delete records, send messages, move money or run shell commands deserves much closer scrutiny and should require human approval for those actions.

• Disable tools you do not need. Most clients let you turn individual tools off.
• Prefer servers that separate read and write tools, so you can allow one without the other.

Step 5: Check Authentication And Permissions

• Remote servers should use OAuth so each user signs in with their own account and the server acts with that user’s permissions, not a shared admin key.
• Local servers often take an API key. Create a dedicated key with the narrowest scope the task needs, never a personal admin token.
• Confirm tokens are not logged, cached in plain text or passed to the model.

Our list of AI agent identity and access management platforms covers tools for managing these credentials at scale.

Step 6: Review The Code And Dependencies

For open-source local servers, a short code review goes a long way.

• Check what the server does at startup and whether it downloads or runs anything else.
• Look for outbound network calls to unexpected domains.
• Scan dependencies for known vulnerabilities and suspicious packages, and pin versions.
• Prefer servers distributed as signed packages or verified container images, such as those in the Docker MCP Catalog.

Step 7: Test It In Isolation

Run the server in a sandbox or container first, with restricted file and network access, and watch what it does. Call each tool with realistic inputs and with deliberately malicious ones, and confirm errors are handled safely. Our list of AI sandboxes for coding agents covers environments built for this.

Step 8: Scan It

Automated scanners can check tool descriptions for injection, compare servers against known-bad lists and flag risky permissions. Several are covered in our list of MCP security tools, and endpoint products in our list of security tools for AI coding agents can risk-score servers already installed on developer machines.

Step 9: Decide Where It Is Allowed

Approve servers for specific uses rather than everywhere. A browser automation server might be fine in a test environment but not on a laptop signed in to production systems. Record approved servers, versions and scopes in an allow-list, and enforce it through project config files or an MCP gateway.

Step 10: Monitor After Approval

An audit is a snapshot. Log tool calls, alert on unusual patterns such as large data reads or new outbound destinations, and re-review servers when they release new versions or change their tools.

MCP Server Audit Checklist

Frequently Asked Questions

Are Official MCP Servers Always Safe?

They are much safer than unknown ones, but still check permissions, keep them updated and limit their tools to what you need.

How Long Does An Audit Take?

A quick review of an official remote server can take minutes. A local community server with broad access deserves an hour or more, including code review and an isolation test.

Should Developers Audit Servers Themselves?

Developers can run the basic checks, but organizations using many agents should keep a central allow-list owned by security or platform teams.

Conclusion

Auditing an MCP server comes down to a few questions: who publishes it, what it can do, what it tells your AI, how it authenticates and what it does when you run it. Answer those before installation, keep an allow-list and keep watching after approval. Combined with the controls in our AI agent security checklist, this turns MCP from a blind spot into a governed part of your stack.