We audited 31 MCP server packages across npm and PyPI.
For every target, we ran two checks: a direct package control against the top-level package, and an installed-tree scan after package installation. The direct package control found 1 finding. The installed trees found 69.
| Scan view | Records | Findings |
|---|---|---|
| Direct package control | 31 | 1 |
| Installed dependency tree | 31 | 69 |
That gap is the point of this report. A top-level package can look clean while the code installed on disk carries known vulnerable dependencies. For MCP infrastructure, that distinction matters because servers are not passive packages. They are tool surfaces an agent can call.
This report stays aggregate and anonymized while notification decisions are handled. The evidence is still enough to act on: package-level checks are not a substitute for installed-tree scanning.
What we scanned
The population was intentionally mixed across official/reference implementations and community or vendor packages:
| Segment | Targets |
|---|---|
| Reference npm servers | 4 |
| Reference PyPI servers | 3 |
| Community/vendor npm servers | 17 |
| Community/vendor PyPI servers | 7 |
That gives 31 targets total: 21 npm packages and 10 PyPI packages. Each target produced two scan records: one direct package control and one installed-tree scan after package installation.
The control is useful because it shows what a shallow package-level check is likely to see. The installed-tree scan is useful because it reflects what an operator actually places into the runtime environment.
What changed when we looked deeper
Across the installed trees, we found 54 unique vulnerabilities across 11 vulnerable targets. The severity distribution was:
| Severity | Findings |
|---|---|
| Critical | 2 |
| High | 34 |
| Medium | 28 |
| Low | 4 |
| Unknown | 1 |
The findings were concentrated. Five installed trees accounted for most of the visible risk:
| Target | Ecosystem | Total | Critical | High | Medium | Low | Unknown |
|---|---|---|---|---|---|---|---|
| Target 1 | npm | 16 | 0 | 8 | 7 | 1 | 0 |
| Target 2 | npm | 14 | 1 | 8 | 3 | 2 | 0 |
| Target 3 | npm | 9 | 0 | 1 | 7 | 1 | 0 |
| Target 4 | PyPI | 8 | 1 | 4 | 3 | 0 | 0 |
| Target 5 | npm | 7 | 0 | 4 | 3 | 0 | 0 |
These labels are anonymized. Named package evidence should go through direct notification before publication.
Why package-level checks miss this
MCP servers are distribution units. Installing one server can pull in dozens or hundreds of transitive dependencies. Vulnerability advisories often apply to those dependencies, not to the top-level server package.
A direct package check can return a true but narrow answer:
No known finding is attached to this top-level package.
That is not the same as:
The code installed for this server is free of known vulnerable dependencies.
The second question is the one operators need answered before they wire a server into an agent environment.
PyPI is part of the MCP surface
MCP scanning is easy to frame as an npm problem. That is incomplete. In this audit, 10 of 31 targets were PyPI packages. Any MCP inventory or scanner that omits PyPI misses a material part of the ecosystem.
Python packaging also carries different metadata. npm has package deprecation. PyPI has yanked releases. This run found no yanked-release signal in the scanned target versions, but the scanner now records that status explicitly so future runs do not lose it.
Registry metadata belongs in the evidence
The scan also captured registry-level status. One target in the population carried a deprecation signal in its registry metadata.
Deprecation is not the same thing as a vulnerability. It is still useful operational evidence. It can mean a package has moved, an install path has been retired, or users need a different run path to receive current updates.
Dependency risk is broader than known CVE or no known CVE. It also includes whether the package an operator installs is the package maintainers expect users to install today.
What operators should do
For MCP servers, the minimum useful baseline is:
- Inventory npm and PyPI targets.
- Install each target in an isolated work directory.
- Record the resolved version, not just the requested version.
- Scan the installed dependency tree.
- Keep the direct package check as a control.
- Capture registry metadata such as deprecation and yanked-release status.
- Treat lockfiles and generated environments as evidence.
The direct package check is still useful. It is fast and makes a good control. It just should not be the only scan standing between an agent and the tool code it will execute.
The takeaway
In this audit, direct package controls found 1 finding. Installed-tree scans found 69. For MCP, the operational unit is not the package name. It is the installed tree.
If you operate MCP servers, agent platforms, or internal tool registries, scan what actually gets installed.
Bindfort Research is expanding this work into a broader MCP ecosystem audit. If you maintain MCP servers or operate an agent platform and want to compare results privately, contact Bindfort Research at research@bindfort.com.