If you pick MCP servers by language, there is one number worth looking at before you commit. I looked at the most severe published advisory anywhere in the resolved dependency tree of each server's listed version, once for npm packages and once for PyPI packages.
The two ecosystems look very different. I'll show the numbers first, then what they can't be read to mean.
The figures
The source is the catalogue report built on the registry snapshot of 2026-10-23, which has 48,551 entries in all. The dependency trees were checked on 2026-10-24.
A known answer exists for 15,686 entries (96.3% of those where the check applies). Split by ecosystem:
| npm | PyPI | |
|---|---|---|
| entries with a known answer | 11,459 of 11,756 | 4,227 of 4,535 |
| critical | 123 (1.1%) | 138 (3.3%) |
| high | 5,471 (47.7%) | 79 (1.9%) |
| moderate | 73 (0.6%) | 96 (2.3%) |
| low | 12 (0.1%) | 5 (0.1%) |
| none known | 5,780 (50.4%) | 3,909 (92.5%) |
Percentages are of the entries with a known answer in that column.
Two things stand out:
- The share with none known is 50.4% for npm and 92.5% for PyPI.
- The mix of severities differs. For npm, almost all advisories are "high". For PyPI, critical (138) outnumbers high (79).
Why a number like this is easy to misread
A published advisory somewhere in a resolved tree does not mean the server can be exploited. It means a package in the tree has an advisory against the version that was resolved. Whether the server's code ever reaches the affected function is a separate question, and I did not examine it.
The two columns also come from different tooling. npm trees come from a lockfile-only resolve, and PyPI trees come from a resolver run with a fixed Python version. I haven't measured how much of the gap comes from ecosystem habits, tree size or tooling, so I won't give a cause. Comparing two columns does not rank two languages.
Left out of the table
- Entries with no answer. In each column, the gap between "known answer" and the total (for example 11,459 of 11,756 on npm) is entries where the tree could not be resolved. They are left out of the percentages and never counted as clean.
- Remote servers. A remote server runs on the vendor's machine and ships no package, so there is no tree to read. These entries are outside the table.
- Anything after 2026-10-24. Advisory databases change daily, and the same tree can read differently next week. I don't claim the table still holds today.
- The package itself. A lookup of a package name alone covers that package only. The tree figures above come from the separate, heavier check.
How to use this if you choose a server
- Look at the entry's own record. "No known critical or high advisory in the package or its dependencies" is one of the nine record checks on each server page.
- If you install from npm, run your own audit tool on the listed version before you install. About half the npm entries with a known answer show an advisory of some severity.
- If you install from PyPI, do the same. The 92.5% with none known is a count on one day, and promises nothing about tomorrow.
How the figures were counted
Each entry's listed version is resolved, and the tree is audited against published advisories. The most severe advisory found is the figure kept. The report keeps the check dates, the base for every percentage and the entries that could not be read.
For the whole catalogue of 15,686 entries, the split was critical 261 (1.7%), high 5,550 (35.4%), moderate 169 (1.1%), low 17 (0.1%) and none known 9,689 (61.8%). The ecosystem split above is the same data cut in two.
Where the data lives
- The catalogue report, dependency advisories section: https://protocolprobe.com/mcp/reports/catalogue#depaudit
- The same data as JSON: https://protocolprobe.com/mcp/reports/catalogue/data.json
- Record checks and what each one reads: https://protocolprobe.com/docs/record-checks
- Changes after the check date: https://protocolprobe.com/mcp/changes
Top comments (0)