Short answer
Before you install, answer five questions: who maintains it, how it installs, what permissions it needs, how fresh the review is, and where your auth or secrets will flow once it is enabled.
If you cannot answer those clearly, the burden of review is on you, not on the tool author.
Recommended path
- 01
Verify the maintainer
Prefer an official vendor or a maintainer with a stable, attributable history over an anonymous proxy or mirror.
- 02
Inspect the install path
Prefer explicit package names, versioned artifacts, or documented config snippets over ad hoc shell installers.
- 03
Match permissions to purpose
A tool that only needs to read docs should not also need shell, broad write, or unrestricted network access.
- 04
Check freshness
A review pinned to an old commit is less trustworthy than a recent assessment of the current repository state.
- 05
Decide the right scope
Install in the narrowest client, workspace, and approval scope that still solves the problem.
Why install scope matters as much as the tool itself
The same tool can be acceptable in one scope and reckless in another. A project-local MCP server with manual approval is a different risk from a user-global server available in every repository with auto-run enabled.
What to save for later
Record the version or commit you installed, the config file you changed, the env vars it depends on, and how you would remove it. Incident response is much easier when you know exactly what changed on day one.
Sources and further reading
Related questions
Security And Trust
What is supply chain risk in AI tools?
Why AI tool supply-chain risk is different from ordinary package risk, and what signals matter most.
Security And Trust
What permissions do skills have?
File access, network access, shell execution, and what really determines the blast radius.
Security And Trust
Are skills safe to install?
Why the answer is “sometimes”, and what separates a safe install from a reckless one.