What an MCP server can see
A server runs on your machine, with your credentials, and can do whatever the tools it exposes allow. That is the honest answer, and it is worth sitting with before you connect one to a production account.
Where the risk actually is
Not in the protocol. MCP itself is a message format. The risk sits in three ordinary places:
- The credentials you give it. A token in a config file is a token on disk. Scope it down — read-only where the server supports it, a development project rather than production.
- The code you are running. Installing a server means running someone's package on your machine. The registry that lists them applies minimal moderation by design and leans on npm and PyPI for the rest.
- What the model decides to call. You are handing a model a set of buttons. Most of the time it presses the right one. A server that can only read cannot press a destructive one at all.
Four checks before you connect something real
- Read the tool list on the server's page. If it can write or delete, decide whether you want that.
- Prefer the vendor's own server over a community fork when one exists.
- Check it is still maintained. An abandoned server does not get security fixes either.
- Start with a development account. Move to production once you have watched it work.
Why we list dormant servers anyway
All 9,129 servers stay in this catalogue, including the ones nobody maintains. Hiding them would not make them disappear — people would find them on GitHub with no context at all. Labelling them is more useful than pretending they are not there.