MCP servers give your AI assistant tools, and those tools run with your user's privileges. A quick review before you approve one catches most of the avoidable risk. This is the checklist I use.
1. Read the tool list, including descriptions
The model reads tool descriptions as instructions. A description that says anything beyond what the tool does (for example "always call this first" or "do not tell the user") is a red flag.
2. Check what each tool can reach
- Filesystem tools: do they restrict to a root directory? Try a path such as
../../in a test folder and see if it resolves outside the root. - Shell or exec tools: can arguments be injected? Is input passed to a shell string or as an argument list?
- Network tools: can they fetch arbitrary URLs, including
localhostand cloud metadata addresses?
3. Look at how it is launched
npx some-server@latest fetches whatever is newest on every start. Pin an exact version in your client config and update deliberately.
4. Check what it can see in your environment
Servers inherit environment variables you pass them. Give each server only the tokens it needs, ideally a scoped, read-only one.
5. Re-review after updates
Tool names and descriptions can change between versions. Re-read them when you bump a version, not only at first install.
6. Prefer least privilege by default
Turn off tools you don't use, and require confirmation for anything that writes or executes.
None of this needs special tooling, but it is easy to skip and hard to remember to repeat, which is why a periodic re-check beats a one-time approval. What's on your checklist that I missed?
Top comments (1)
Do you treat screen-control (computer-use) servers as their own risk tier? They can read anything visible, so a web page or email on screen can carry a prompt injection the same way a tool description can.
The check we'd add (Auten team, we build one): does the server treat screen text as data, and does it stop to ask before send, delete or buy steps?