Are MCP servers safe? 8 checks before you add one

What can an MCP server do on your machine?

The Model Context Protocol, MCP, is an open standard for connecting AI tools to external data sources, as Anthropic’s Claude Code docs describe it. A server adds tools your agent can call: query a database, read a ticket, drive a browser.

The official MCP project has a guide to running local servers safely, and it starts with a blunt description. When you run an MCP server locally, you download code from the internet and run it as a child process of your user account. That process inherits your environment variables, can read anything your account can read, including SSH keys, cloud credentials and browser profiles, and can open outbound network connections anywhere. The protocol does not govern any of that. How you run the process does.

The guide’s summary is the right mindset: treat a third-party local server as untrusted code with exactly the privileges you hand it, and hand it as few as possible. Here are eight checks that follow from it.

Does it need to run on your machine at all?

Often it does not. A server that only wraps a web service gains nothing from running on your laptop, and you take on all the risk below for no benefit. The MCP guide says to prefer the remote version where one exists, because it runs no code on your machine.

Keep local servers for jobs that need your files, your local tools or your hardware.

Who published it?

A listing in a package registry is not an endorsement. The MCP guide suggests you identify the publisher and tie the package to a real source repository with recent, plausible activity, and verify the exact package name, because typosquatting is the cheapest attack available.

Anthropic’s docs carry a matching warning: verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection.

Is the version pinned?

Install a specific version, not latest, so that a compromised future release cannot arrive by auto-update. The guide adds a detail that surprises people: pinning a package that you launch with a tool such as npx or uvx fixes only the top-level package, and its dependencies are usually resolved fresh. Pinning a container image by digest freezes the whole tree.

What do its tool descriptions say?

Read them. Tool names and descriptions are instructions that your model reads, so a server can hide directives in them. The MCP guide names the risk: tool poisoning, and a rug pull, where a server quietly changes its definitions after you approved it.

You can look at what a server exposes without a model in the loop. The MCP Inspector lists every tool a server offers. If a description contains instructions unrelated to the tool’s job, remove the server. Keep the list short, too, because every server you add shares the same model context.

What can the process reach?

Run third-party servers in a container with nothing mounted beyond what the server needs. The guide ranks process isolation as its most effective mitigation, because it protects you even when the other checks fail. A container turns “can read my SSH keys” into “can read an empty folder.”

Give each server only its own credentials, through its per-server configuration rather than your shell profile, and scope the token narrowly, for example to one repository. Grant filesystem access to one project directory, read-only if possible. The guide warns that configuration allowlists are cooperative boundaries: a well-behaved server respects them, and a malicious one does not.

Does it need the network?

If a server works only on local files, deny it network access. With containers that is one flag, --network=none. For servers that do need the internet, know where they should be talking, and restrict the rest with a firewall or an egress proxy.

What happens when a tool misbehaves?

Make sure your agent asks before dangerous calls. In Claude Code you can write permission rules for MCP tools, such as mcp__github__get_* to allow one server’s read tools, or a deny rule on mcp__* to block them all, as the permissions docs show. Codex’s docs say destructive MCP tool calls always require approval when the tool advertises a destructive annotation.

Also remember a project can ship its own .mcp.json. Claude Code asks you to approve project servers, and a cloned repository cannot approve its own, so read the list before you click.

Do you still use it?

Remove servers you no longer need. The MCP guide’s first tip is to open your client’s configuration, delete what you do not use, and make sure you know where each remaining server comes from and that its version is pinned. In Claude Code, /mcp lists configured servers and lets you disable the ones you are not using, which also trims the context they add.

What is the five-minute version?

If you do nothing else, do these. Remove the servers you do not use. Prefer a remote server when the job does not need your files. Install only servers whose source you can read and whose publisher you can identify, at a pinned version. Skim each server’s tool list once. And run every third-party server in a container with nothing mounted except the directory it is meant to work on.

That is close to the “if unsure” defaults the MCP guide gives for each of its sections.

See a server’s tools before an agent does

In SwarmPane, MCP servers are added as a command you trust to run on your computer. You verify the server and see its tools before an agent uses them. Choosing how isolated the process is remains your call, so use the checks above.

Our earlier post on connecting tools without losing track of access covers the principles.

SwarmPane runs the agent CLIs and accounts you already have. Start with a 7-day trial for $1 and review your MCP servers in one place.