Installing an MCP server is not like installing a library. A library runs when you call it. A server hands an autonomous agent a set of tools and then the agent decides when to use them, on inputs you did not write.
1. What can it reach
Not “what does it do”, which is the marketing question. What paths, what accounts, what money. A server that reads your calendar and a server that writes to it are different products with the same one line description, and the description is usually written by someone excited about the first case.
If the README does not have a section that answers this, that absence is the answer.
2. What is in the tool descriptions
The text describing each tool is fed to your model as instructions. That text comes from the server author, and your agent will read it with the same attention it gives your own prompt. A tool description is therefore a prompt you did not write, running inside your session.
Read them. All of them. It takes five minutes and it is the single highest value five minutes in this entire process.
3. Who ships the updates
You audited version 0.3.1. Version 0.3.2 arrives on its own if you pinned nothing, carrying new tool descriptions from whoever now controls that package. Pin the version. Re read on upgrade. This is ordinary supply chain hygiene and it applies here more sharply than usual, because the payload is instructions rather than code.
The uncomfortable summary
Nobody is auditing these for you. Not the registries, not us. We ask every entry on this site to declare its blast radius, and that declaration is made by the publisher, in good faith, and unverified. It is better than nothing and it is a long way from a guarantee. Read the code.
