Which MCP servers are safe to install?

The Model Context Protocol (MCP) lets assistants such as Claude Desktop or the Cursor code editor connect to small programs called servers that give them new tools: reading files, searching a database, sending email. Community servers have multiplied since MCP was introduced in November, and installing one is often a single line in a configuration file. That ease is exactly why it deserves a pause.

Two facts shape the risk. First, a local MCP server is a program running on your machine with your user's permissions, so it can do whatever a program you downloaded could do. Second, your assistant reads each server's tool descriptions, the text that explains what each tool does, and treats them as guidance. The MCP specification published on March 26 says it plainly: tools amount to arbitrary code execution, descriptions of tool behaviour should be treated as untrusted unless the server is trusted, and the app should get your explicit consent before any tool runs. The protocol itself can't enforce those principles; the apps and you have to.

A vetting checklist

Use this before you add any server. The example server in the last column is illustrative.

Then a few habits. Add servers one at a time. Keep servers that handle sensitive data (email, finance, credentials) out of the same assistant session as servers you trust less. Leave the confirmation prompts switched on, and actually read what a tool call is about to send before you approve it. And remember the configuration file itself can hold keys for every server you use, which makes it a prize worth protecting.

Checking tool descriptions yourself

Most chat apps show a short tool name, not the full description the model receives. To see everything, connect the server to the MCP Inspector, the developer tool from the MCP project, and list its tools; it displays each description and input field in full. Look especially for long descriptions on simple tools, for words like "important" or "before using this tool," and for unexpected extra input fields that the task doesn't need.

What is tool poisoning?

Tool poisoning is a name for an attack published on April 1 by Invariant Labs, a security research company. A malicious MCP server hides instructions inside a tool description. The user sees a harmless tool name; the model sees the full text and may follow it. It is a form of indirect prompt injection: instructions arriving through data the model processes rather than from the user.

In their example, a tool that claims simply to add two numbers carries a description telling the model to first read a configuration file and the user's private SSH key (the secret file used to log in to servers), and pass their contents in an extra input field, while chatting about arithmetic so the user doesn't notice. Tested with Cursor, the agent did read the files and send them to the malicious server. The confirmation dialog didn't reveal the full input, so approving the call didn't protect the user.

The researchers describe two variations. In a rug pull, a server you approved later changes its tool descriptions, so your earlier review no longer applies. In shadowing, a malicious server's description changes how the model uses a different, trusted server's tool; in their test, an instruction from a fake addition tool made the agent send every email to the attacker's address, whatever recipient the user had asked for.

Their suggested fixes are aimed mostly at app makers: show users full tool descriptions, pin servers and tools to verified versions with a checksum (a fingerprint that changes if the content changes), and stop servers from influencing each other. Until apps do that, the checklist above is your protection: fewer servers, known sources, fixed versions, and descriptions you have read yourself.