A heads-up on an abandoned-namespace issue affecting the tool you acquired from Invariant Labs.
Invariant published mcp-scan to npm as a thin wrapper around the Python tool from v0.1.5 (2025-04-24) to v0.2.1 (2025-05-22), then removed npm support in commit ed8d4d8 on 2025-06-05 and unpublished those versions. On 2026-03-23 the freed npm name was re-registered by an unrelated third party, and it now serves a different MIT-licensed tool (currently v2.0.2).
The practical effect: any docs, blog posts, or pipelines written during that 2025 window still say npm i mcp-scan, and today that installs someone else's program. I verified the current npm package (v2.0.2) never connects to the MCP server at all: it pattern-matches the client config file and never calls tools/list, so it cannot see a tool description. Against a deliberately poisoned demo server, whose tool description carried a hidden instruction to read the user's SSH key, it reported no poisoning finding. It also emitted a false CRITICAL "Exposed Pinecone API Key" on a long file path containing no key, and a MEDIUM "external network endpoint" on a local path. That is false assurance inside a security step, under a name people associate with your tool.
Might be worth (a) publishing canonical-install guidance somewhere more findable than the repo README, stating plainly that there is no official npm package, and pointing at both channels you already ship (the signed standalone binaries, and the snyk-agent-scan PyPI package). Worth noting that MCP tooling skews heavily JS/TS, so "install uv, then uvx" is friction for much of the audience. I suspect that gap is part of why people reach for npm i mcp-scan at all. And (b) npm's dispute policy rules out squatting claims outright and points to a trademark or IP claim as the only route to reclaim or redirect a name. Whether there is a basis for that in "mcp-scan" is your call and not something I can assess from outside, but it is a lever available to you and not to an outside reporter.
Reproduction and full details: https://manzambi.com/writing/your-security-scanner-is-a-supply-chain-too
I work in AI/MCP security and am happy to share more.
Joseph Manzambi
A heads-up on an abandoned-namespace issue affecting the tool you acquired from Invariant Labs.
Invariant published mcp-scan to npm as a thin wrapper around the Python tool from v0.1.5 (2025-04-24) to v0.2.1 (2025-05-22), then removed npm support in commit ed8d4d8 on 2025-06-05 and unpublished those versions. On 2026-03-23 the freed npm name was re-registered by an unrelated third party, and it now serves a different MIT-licensed tool (currently v2.0.2).
The practical effect: any docs, blog posts, or pipelines written during that 2025 window still say npm i mcp-scan, and today that installs someone else's program. I verified the current npm package (v2.0.2) never connects to the MCP server at all: it pattern-matches the client config file and never calls tools/list, so it cannot see a tool description. Against a deliberately poisoned demo server, whose tool description carried a hidden instruction to read the user's SSH key, it reported no poisoning finding. It also emitted a false CRITICAL "Exposed Pinecone API Key" on a long file path containing no key, and a MEDIUM "external network endpoint" on a local path. That is false assurance inside a security step, under a name people associate with your tool.
Might be worth (a) publishing canonical-install guidance somewhere more findable than the repo README, stating plainly that there is no official npm package, and pointing at both channels you already ship (the signed standalone binaries, and the snyk-agent-scan PyPI package). Worth noting that MCP tooling skews heavily JS/TS, so "install uv, then uvx" is friction for much of the audience. I suspect that gap is part of why people reach for npm i mcp-scan at all. And (b) npm's dispute policy rules out squatting claims outright and points to a trademark or IP claim as the only route to reclaim or redirect a name. Whether there is a basis for that in "mcp-scan" is your call and not something I can assess from outside, but it is a lever available to you and not to an outside reporter.
Reproduction and full details: https://manzambi.com/writing/your-security-scanner-is-a-supply-chain-too
I work in AI/MCP security and am happy to share more.
Joseph Manzambi