Third-Party MCP Servers: A 30-Minute Audit Before Connecting

Before connecting a third-party MCP server to your coding agent, spend less than 30 minutes checking who maintains it and since when, what file, network and shell permissions it requests versus what it actually needs, and whether its tool descriptions can inject hidden instructions into the model. Without those three checks, the server can read your credentials with the same permissions your agent has.

An MCP server isn't a library you import that runs inside a language sandbox: it's an independent process your agent launches and talks to over stdio or HTTP, and that process inherits the environment variables, filesystem and network identity of whoever launched it. If your coding agent runs as your system user and has access to API keys, deployment tokens or database credentials in environment variables, the MCP server you connect can read them without the protocol stopping it, because it defines no default isolation boundary. This contrasts with browser extensions or mobile apps, which declare permissions in a manifest that the operating system or the store reviews before installation. In MCP that review layer doesn't yet exist in a standardized way: each server decides which tools it exposes and what each one can do, and the client — your agent — trusts that declaration. Most MCP servers published in community registries go through no signing or code audit process before being listed. Connecting one is, in terms of attack surface, equivalent to granting arbitrary code execution to an unreviewed npm or PyPI package, with the added risk that this code can act directly on your production systems if the agent has that access.

Split the audit into three ten-minute blocks and don't skip any of them, even if the server looks trustworthy at first glance. The first block looks at who wrote the code and since when; the second looks at what that code can do once connected to your agent and how to contain it; the third defines how you'll disconnect it if something goes wrong. None of the three replaces the others: a trusted maintainer can publish a server with excessive permissions by mistake, and a server with minimal permissions can come from an account created last week to steal credentials from developers who trust that it 'looks like a serious project'. This order matters because each block filters different risks that are cheap to detect before investing time in the next one. If the server fails the first block, stop there: no isolation setup compensates for dubious code provenance. Keep the results of the three blocks in a short document — two lines per point is enough — so you don't repeat the whole audit every time another team member wants to use the same server.

Minutes 0-10: provenance and code surface

• Public repository with a real commit history, not a single initial commit with all the code already written.
• Identifiable maintainer with prior activity, not a profile created the same week as the package.
• Declared license and dependencies listed in package.json or requirements.txt, not obfuscated.
• No precompiled binaries without matching source code in the repository.
• Open security issues reviewed one by one, not just the ones closed without explanation.

Minutes 10-30: what it asks for, what it can touch, and how to isolate it

• Exact list of tools the server exposes and what arguments each one accepts.
• Whether any tool allows shell execution, writing outside a scoped working directory, or outbound HTTP requests without a domain allowlist.
• Grep for process.env / os.environ in the source code to see which environment variables it reads on startup.
• Outbound calls to undocumented telemetry or analytics domains not mentioned in the README.
• Whether it requests credentials with broader scope than the task needs, such as an admin token when only read access is required.
• Run it first in a container or VM separate from any environment with real credentials, never on the same machine as a production agent.
• Use minimal-scope, revocable credentials for the duration of the test, and decide in advance how you'll kill it if something goes wrong.

There's a pattern no 'permissions at install' checklist catches: the MCP tool rug pull. A server can pass your initial audit with a harmless tool definition and, weeks later, through a silent version update, change that same tool's description or behavior without your agent asking for approval again, because most MCP clients only confirm the first time they see a tool name, not every time its definition changes. This means auditing an MCP server isn't a one-time installation event — it requires pinning the version, or the package hash, and reviewing the diff before every update, just as you would with a critical production dependency. The protocol itself doesn't require signed versions or verifiable change notifications, so the responsibility for catching this falls entirely on whoever installed it. A simple package hash stored alongside the audit date is enough to know, months later, whether what's running today is the same thing you approved back then. In practice, very few teams treat their MCP servers with the same version-control rigor they apply to their backend dependencies, precisely because MCP's whole selling point is frictionless installation — and that's the real tension in the protocol.

We don't recommend auditing every MCP server a team tries with the same level of depth. If you did, nobody would use MCP: the friction would kill the very tool that's supposed to save time. What we do argue for is classifying by risk level before deciding how much time to spend reviewing each one.

This 30-minute guide makes sense for an MCP server that will have access to production credentials, to your code repository with write permissions, or to client systems. It doesn't make sense to apply it the same way to an MCP server that only queries a library's public documentation, runs in a test environment with no real secrets, or that you use for five minutes as a personal experiment you then uninstall. Treating every installation like a production deployment creates security fatigue: the team stops auditing anything because auditing everything is unworkable, which is exactly the opposite of what you're trying to achieve. We ourselves, in quick internal tests, skip steps of this checklist when the environment is fully disconnected from real data — not out of laziness, but because the actual risk in that case is close to zero. The key is deciding, before installing anything, what access the agent using that MCP will actually have, and reserving the full audit for cases where that access includes something you can't afford to lose.

• We classify the server by the access level it will have: documentation read-only, repository write access, or production access.
• We review the full source code when it will touch real credentials or infrastructure, not just the README.
• We test it first in an isolated environment, with no connection to the client's systems.
• We document which tools it exposes and pin the version before giving the green light for ongoing use.