Checking an MCP server before you install it

Where the risk actually is

• The code: a local server can do anything your user account can.
• The package: the name you install may not belong to the project you think it does. While building MCP Shelf we found popular servers whose npm names belong to unrelated authors.
• The data: a remote server sees everything you route through it.
• Prompt injection: a tool that returns text from the web or from other people can steer what the assistant does next.

A checklist

1. Find the source. No public repository, no named owner: skip it.
2. Match the package to the repo. On npm, check the repository field; on PyPI, check the project links. A mismatch is a red flag.
3. Read the tool list. Writes, deletes and shell commands should be ones you expected.
4. Compare what it asks for with what it does. A read-only tool asking for an admin token is wrong.
5. Look at activity: recent commits, open issues, how fast security issues get answered.
6. Prefer a pinned version over running whatever is on a branch today.

Limit the damage if it goes wrong

• Use narrow tokens: read-only, one repository, one project.
• Give each server its own token so you can revoke one at a time.
• Start database and cluster servers in their read-only modes.
• Keep secrets in your user-level config, not a project file that gets committed.
• If a secret was ever committed, rotate it. Deleting the line does not remove it from git history.

Questions