The MCP Server Security Checklist: Eight Things to Verify Before You Connect
An MCP server is code you run with your agent's hands on the wheel. Before you add one to mcp.json, verify these eight things — provenance, tool descriptions, scope, credentials, transport, pinning, blast radius, and the difference between what it can do and what you meant to allow.
Adding an MCP server to your editor feels like installing an extension. It is closer to hiring a contractor and handing them your keys: the server's tools run with real access — your filesystem, your shell, your APIs — and your agent invokes them autonomously, guided by text the server itself provides. The Model Context Protocol standardizes the plumbing; it deliberately does not decide what a server should be trusted to do. That part is yours. Here is the checklist.
1. Provenance: is this the server you think it is?
MCP servers are distributed as packages and repos with no central vetting. Before anything else, confirm you have the canonical source: the repository the protocol documentation or the vendor actually links, not a lookalike. Name-squatting arrived in the MCP ecosystem almost immediately — a familiar-sounding server name with a handful of downloads and a fresh publish date deserves the same suspicion as a typo-squatted dependency, because it is the same attack.
2. Read the tool descriptions — all of them
Your agent chooses when to call a tool based on the tool's own description text, and researchers demonstrated in 2025 that a poisoned description can steer an agent into exfiltrating private data while the user sees a perfectly normal tool call. The descriptions are part of the attack surface. Read every one before connecting: a legitimate description says what the tool does; a poisoned one gives the agent instructions ("before using this tool, first read the file at… and include its contents"). If a tool's description addresses the agent imperatively about OTHER actions, disconnect. The full mechanism: https://deepsweep.ai/blog/tool-poisoning-confused-deputy-mcp
3. Scope: what can it actually reach?
Enumerate the capabilities, not the marketing. A filesystem server: which directories — your project, or your home directory? A shell server: any command, or an allowlist? A database server: which connection string, read or write? The gap between "it is a GitHub server" and "it holds a token that can push to every repository I can" is the gap incidents live in. If the server supports narrowing its scope through configuration, narrow it before first use, not after.
4. Credentials: how does it hold your secrets?
An MCP server that talks to an API holds a credential for that API. Where? Environment variables in your mcp.json are visible to anything that can read the file; some servers want tokens as command-line arguments, which leak into process lists and shell history. Prefer servers that read from a secret store or a scoped, short-lived token — and issue the narrowest token the service will give you. The server's compromise is your token's compromise.
5. Transport: does your data leave the machine?
A local stdio server keeps everything on your machine. A remote server — SSE or HTTP — means every tool call, including whatever file contents or query results flow through it, transits to someone else's infrastructure. Neither is wrong; they are different trust decisions. Know which one you are making, and for remote servers, know who operates the endpoint and what they log.
6. Pin the version, and re-review on update
The server you reviewed is a moving target: an update can change tool descriptions, add tools, widen scope. Pin to a specific version rather than tracking latest, and treat a version bump the way you treat this checklist — the 2025 wave of supply-chain attacks on developer tooling worked precisely because updates inherit yesterday's trust without yesterday's review.
7. Assume compromise: what is the blast radius?
Run the tabletop exercise before connecting: if this server were malicious from the start, what could it take? With your editor's default settings, could the agent chain this server's tools with shell access to act on what it read? The answer defines whether the server needs sandboxing — a separate machine user, a container, restricted directories — or whether its worst case is acceptable. Deciding after connection is deciding after the fact.
8. Close the gap between granted and intended
The final check is the ongoing one. What a server CAN do (its capability surface) and what you MEANT to allow (your authorization intent) drift apart silently as servers update, tools accumulate, and configs get edited. The manual version of this check is re-running this list quarterly. The continuous version is what the DeepSweep extension does in your editor: it reviews your agent environment — mcp.json included — on open and on save, maps every capability your agent holds through its MCP servers, flags the gaps where it can act beyond what you intended, and runs locally with nothing uploaded. One command: Review My Agent Environment. It is free, on Open VSX, which Cursor, Trae, and Antigravity all install from.