What You Do Not Know Can Hurt You
Every MCP server you install brings its dependencies along. An npm package with 5 direct dependencies might transitively depend on 200 packages. Each of those packages is code running on your machine, potentially with access to the data your MCP server processes.
Most users never look at these dependencies. They install the tool, verify that it works, and move on. This is understandable but risky. A supply chain attack through a compromised dependency is one of the most practical attack vectors in the current ecosystem.
What Good Transparency Looks Like
A transparent AI tool makes its dependency information easy to find and understand. The README lists major dependencies and explains why each is needed. The lockfile is committed to version control, ensuring reproducible installs. The project runs dependency auditing as part of its CI pipeline, and the results are visible to users.
Some projects go further, providing a dependency graph visualization, a bill of materials, or regular dependency audit reports. These practices are still uncommon in the AI tool ecosystem but represent a direction that benefits everyone.
Evaluating Dependencies
When evaluating an AI tool's dependencies, focus on three factors. The total count gives a rough sense of attack surface. More dependencies mean more potential vulnerability points. The maintenance status of key dependencies matters: are they actively maintained, or have they been abandoned? And known vulnerabilities in any dependency should be a red flag that the tool's maintainer hasn't addressed.
Automated tools make this evaluation practical. npm audit checks for known vulnerabilities. npm ls shows the dependency tree. Third-party tools like Snyk provide more detailed analysis including license compatibility and maintenance status. These checks take minutes but provide valuable insight into the tool's security posture.
Security scoring platforms that automatically assess dependency health across the ecosystem save individual users from performing this analysis manually. When a platform's security grade accounts for dependency vulnerabilities, a high grade implies that the dependency tree has been checked and found acceptable.
The Maintainer's Responsibility
Tool maintainers have a responsibility to keep dependencies updated and to minimize unnecessary dependencies. A tool that pulls in a large framework to use one small utility function is adding risk without proportional benefit. Preferring smaller, focused dependencies over large, multi-purpose ones reduces the attack surface.
Regular dependency updates, especially security patches, demonstrate that the maintainer takes supply chain security seriously. A project that hasn't updated its dependencies in months might have accumulated vulnerabilities that newer versions have fixed.
For users, checking when dependencies were last updated is a quick proxy for maintenance quality. A project with dependencies pinned to versions from a year ago is likely carrying known vulnerabilities. Platforms that surface this information help users make these assessments quickly.