Connecting an MCP server is not like installing an app. When you add a Model Context Protocol server to Claude, Cursor, or any AI client, you are handing it tools that take real actions — reading your files, querying your database, opening pull requests, issuing refunds. The AI will call those tools on instructions it reads at runtime, and some of those instructions can come from places you do not control.
This is not hypothetical. In January 2026, a researcher published an exploit chain against Anthropic’s own Git MCP server that reached remote code execution through prompt injection alone. Three months later, Microsoft’s Azure DevOps MCP package shipped with a missing authentication layer on a server that could touch repositories and pipelines. The OWASP project now maintains an MCP Top 10 of security risks. The tooling is young; the blast radius is not.
So before you connect any MCP server, run it through this checklist. It takes a few minutes per server and it is the difference between adding a capability and adding a liability.
1. Check the source and the maintainer
Start with provenance. Is the server open source with a public repository you can actually read? Who maintains it, and are they responsive to issues and security reports? An official, first-party server (from the vendor whose API it wraps) is a very different risk profile from an anonymous community package with three stars and no commit history.
Prefer servers you can inspect. If the code is closed and the operator is unknown, you are trusting a black box with live access to your systems.
2. Match the tools to the server’s stated purpose
Read the full tool list before you connect, and compare it to what the server claims to do. This is where permission creep hides. A server that bills itself as a “read-only database explorer” has no business exposing an execute_sql tool with write access. A documentation-lookup server does not need to write files.
Every tool a server exposes is a capability you are granting your AI. If a tool is not necessary for the job you connected the server to do, that mismatch is a red flag worth investigating.
3. Read the actual tool descriptions
Tool descriptions are not just documentation — the AI reads them as instructions. That makes them a prime vector for tool poisoning: hidden text in a tool’s description that tells your assistant to do something you never asked for, like exfiltrating a file or calling another tool first.
Read the raw descriptions, not the marketing. Watch for instructions aimed at the model (“always call X before Y”, “do not mention this to the user”), and for invisible or unusual characters used to smuggle text past a human skim. If a description is talking to the AI instead of describing the tool, stop.
4. Understand how credentials are handled
Most useful servers need an API key or token. Find out where it lives. Is it stored locally in your own config or secrets manager, or is it sent to a remote server the operator controls? Never commit an mcp.json with keys to git, and for a team, never share one key across everyone — you lose all attribution and can’t revoke one person without rotating for all.
5. Check the transport and authentication
For remote servers, connections should use TLS with a certificate from a recognized authority — self-signed certs are not acceptable in production. Prefer OAuth-based auth over static shared API keys where the server supports it, so access is per-user and revocable.
6. Plan for drift
Vetting a server once is not enough. A server you approved today can push an update tomorrow that changes a tool’s behavior or rewrites its description — and nothing about your local config will tell you. This is one of the hardest parts of MCP security to handle manually, because it requires you to re-audit servers you already trust, on a schedule, forever.
7. Start read-only and least-privilege
When you do connect, start with the narrowest access that works. Enable read-only tools first, expand to write access only when you have a specific need, and keep anything destructive behind an explicit approval step. “Allow all” is a policy you should never reach for on day one.
Automate the checklist with a gateway
This is the case for putting an MCP gateway in front of your servers instead of wiring each one directly into every client. A gateway turns the checklist above into something that runs automatically, on every server, every time.
That is what we built gate to do. Every server is scanned for prompt injection and hidden instructions before it goes live, checked against a verified catalog for provenance, and re-checked for drift whenever its tools change — so you find out the moment a description you approved gets rewritten. On top of that, you set an allow / ask / block rule for every tool, keep sensitive actions behind approval, and get a plain-language log of every call. It is the seven-point checklist, enforced for you.
The bottom line
MCP is one of the most useful things to happen to AI tooling, and also one of the easiest ways to hand an attacker a foothold. Treat every new server as a security decision: check who made it, match its tools to its purpose, read the descriptions, control the credentials, and plan for the day it changes. Do that by hand while you have two servers — and automate it before you have twenty.