Vetting a third-party MCP server before you connect it

The supply-chain risk for MCP servers is higher than for typical software dependencies for two reasons.

First, MCP servers are code that executes in a privileged context. They run with the permissions granted to the MCP server process — which may include filesystem access, network access, and the ability to call external APIs. A malicious or compromised MCP server can use these permissions to exfiltrate data, modify files, or make network requests on behalf of the host system.

Second, MCP servers have a direct channel into the model's context. The tool descriptions they serve influence the model's behaviour. The data they return from tool invocations is injected into the model's context window. A server that wants to influence what the model does has a legitimate, designed channel to do it. Traditional supply-chain attacks target code execution; MCP supply-chain attacks can target model reasoning.

Vetting a third-party MCP server before production connection involves four sequential steps. Each step is a gate: a failure at any step should pause the connection decision pending resolution or explicit risk acceptance.

1. Source review — understand who built it and how it is maintained.
2. Tool manifest audit — understand what it exposes to the agent.
3. Permission scope review — understand what host-system access it requires.
4. Dependency check — understand what the server itself depends on.

These steps are not a one-time exercise. They should be repeated when the server version changes, when the server's deployment configuration changes, and on a periodic cadence (annually at minimum) regardless of detected changes.

Source review answers the question: who built this, and can I rely on them to maintain it responsibly?

Is the code open source?

Open-source MCP servers can be reviewed directly. Closed-source servers require trust in the vendor without the ability to verify. For a production deployment, closed-source MCP servers should be treated with the same level of scrutiny as any commercial software handling sensitive data.

Who maintains it?

A server maintained by a single individual with no organisational backing is higher risk than one maintained by a team or a vendor with a security disclosure process. Questions to answer: what is the contributor history? Is there a documented security vulnerability disclosure process? When was the last commit? Is the maintainer identifiable and accountable?

What is the update process?

How are updates delivered? Can a malicious update be pushed without warning? Is there a changelog? Are releases signed? Does the organisation pin the version in its deployment configuration, or does it track the latest release automatically?

In assessed systems that use third-party MCP servers, the update process is the most common unaddressed supply-chain risk. Organisations pin the initial version correctly and conduct a reasonable initial review, but have no process to re-review when the version changes. The MCP server is deployed once and treated as a static dependency, where software supply-chain hygiene would require it to be treated as a live, changing component.

The tool manifest audit answers the question: what does this server expose to the agent, and is it limited to what the use case requires?

What tools does it expose?

List every tool in the manifest. For each tool: what does it do, what parameters does it accept, what systems does it access, and what is the worst-case outcome if the model invokes it with attacker-controlled parameters?

Are the tools in scope for the use case?

A third-party MCP server may expose a broad set of tools that were appropriate for its general-purpose design but include capabilities that are not required for the specific deployment. Every in-scope tool is a capability the model can use. Every out-of-scope tool is unnecessary attack surface.

Some MCP servers support selective tool exposure — the client can specify which tools to include in the session. Where this is supported, the deployment configuration should include only the tools the use case requires. Where it is not supported, the tool surface analysis should document the excess capability as a residual risk.

Are descriptions accurate and not manipulative?

Review each tool description for the tool-poisoning indicators described in Tool poisoning in MCP servers: imperative language, unusual length, encoded characters, and instructions embedded in parameter descriptions.

The permission scope review answers the question: what does the server need from the host system to function, and is that access scoped to the minimum required?

MCP servers require different types of host-system access depending on their function:

• Filesystem access — for servers that read or write files. Scope: which directories? Read-only or read-write?
• Network access — for servers that call external APIs or access databases. Scope: which endpoints? What credentials are used?
• Process execution — for servers that run commands or scripts on the host. This is the highest-risk permission category and should be evaluated with extra scrutiny.
• Environment variables and secrets — for servers that read credentials or configuration from the environment. Which variables? Are secrets passed in a controlled way (secrets manager) or through the environment?

For each permission category the server requires, document: is this permission necessary for the tools that are in scope for this deployment? Is it scoped to the minimum access level (read-only where write is not needed, specific directory where full filesystem access is not needed)?

An MCP server is not just its own code. It brings with it everything its own dependencies depend on. A server that is itself well-written can be compromised through a malicious or vulnerable dependency. The dependency check applies standard software supply-chain hygiene to the MCP server's full dependency tree.

The dependency check should cover:

• Known vulnerabilities— run the server's dependency manifest (package.json, requirements.txt, go.mod, etc.) through a vulnerability scanner (npm audit, pip-audit, govulncheck). Document the finding count and severity.
• Dependency provenance — are all dependencies published to standard package registries (npm, PyPI, crates.io)? Are any dependencies sourced from personal GitHub repositories or uncommon registries?
• Dependency pinning — are dependencies pinned to specific versions? Floating dependencies (latest, ^1.x) allow the dependency to change without a corresponding change to the server version.
• Network-accessing dependencies — do any dependencies make outbound network calls? Analytics, telemetry, and update-check libraries in server dependencies are a vector for data exfiltration in a server-side process.

A security review of a third-party MCP server should produce:

• Source review notes— documented assessment of the server's maintainer, update process, and security disclosure history.
• Approved manifest baseline — a version-controlled copy of the tool manifest at the reviewed version, with each tool justified or flagged.
• Permission scope documentation — the access permissions granted to the server process, with a justification for each.
• Vulnerability scan output — the output of a dependency vulnerability scan for the reviewed version.
• Version pinning confirmation — the server version is pinned in the deployment configuration and the review cadence for version updates is documented.

For the full MCP security review, see An MCP server security review checklist.