io.github.GuardBeePublished by GitHub account GuardBeev0.3.1Updated Nov 3, 2026
Checks declared npm/PyPI dependencies against real registries to catch slopsquatting
Local MCP server that checks a project's declared npm and PyPI dependencies against the live registries to flag hallucinated or slopsquatted package names.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Follow the launch instructions in the repository.
🇬🇧 English | 🇹🇷 Türkçe | 🇨🇳 中文 | 🇯🇵 日本語 | 🇰🇷 한국어 | 🇧🇷 Português | 🇪🇸 Español | 🇩🇪 Deutsch
[npm version] [npm downloads] [License: MIT]
An MCP (Model Context Protocol) server that checks every dependency declared in a project's own manifest (package.json, requirements.txt, pyproject.toml) against the real npm/PyPI registry — not a local database, an actual network lookup.
LLM coding assistants hallucinate plausible-sounding package names at a measurable rate — research on open-source models puts it around 21.7%. Attackers know this and pre-register exactly those names on npm/PyPI, so the next person who copies the same suggestion doesn't get an install error — they get the attacker's code instead. This is slopsquatting, and unlike a typo-squat, there's no misspelling to catch by eye: the hallucinated name is often more plausible-sounding than the real package it was meant to be.
Telemetry is off by default. With
GUARDBEE_TELEMETRY=1it sends the server, tool, success, duration and short parameter values such as a file path; longer strings and fields likecontent,tokenorpasswordare replaced with a placeholder. See@guardbee/mcp-telemetry.
There's no way to maintain a local "known bad" list for this — the whole point of a slopsquat is that it's a new name, registered specifically to catch a specific hallucination, possibly hours before someone runs npm install. A static pattern can't know that; only asking the registry "does this exact name exist right now" can. This package only checks a project's own directly declared dependencies (the dependencies/devDependencies/peerDependencies/optionalDependencies sections of package.json, or requirements.txt/pyproject.toml for Python) — not the full resolved lockfile tree. Transitive dependencies were already vetted by whichever maintainer published the package that depends on them; the actual risk moment is when a new name gets typed (by a human or an AI assistant) directly into your own manifest.
A name that doesn't exist at all is unambiguous and reported critical — verify the correct name before you or a teammate installs it. A name that does exist but was only published in the last 30 days is reported low/informational, not critical: this is routine for real new packages too, and on its own doesn't prove anything malicious — it's a "worth a second look" signal, not a verdict.
[project] dependencies and Poetry's [tool.poetry.dependencies])@scope/name) handled correctly — found and fixed a real URL-encoding bug during development (encodeURIComponent on the whole name double-encodes the registry's own @scope%2Fname convention, producing a URL the registry doesn't recognize as a single package)react, vitest, requests) and deliberately hallucinated ones — caught both hallucinated names, zero false positives on the real ones. Also run against this monorepo's own package.json files as a dogfooding check: zero false positives on real dependencies, and one genuinely correct low-severity finding (@guardbee/mcp-telemetry, itself only ~2 weeks old on npm at the time) — exactly the intended "worth a look, not an alarm" behavior.guardbee.yml)@guardbee/mcp-dependency-auditor for known-CVE checking).MIT — GuardBee
Questions, ideas, or a false positive? Start a thread in GitHub Discussions or open an issue. If GuardBee is useful to you, a ⭐ on the repository helps others find it.
Source: packages/slopsquat-scanner/README.md at commit bc5997d
Check every dependency declared in a package.json (dependencies, devDependencies, peerDependencies, optionalDependencies) against the real npm registry -- flags any package name that doesn't exist at all (a likely LLM-hallucinated dependency an attacker may have pre-registered, i.e. 'slopsquatting'), and separately notes any that exist but were only first published very recently.
directoryrequiredCheck every dependency declared in requirements.txt or pyproject.toml against the real PyPI registry -- flags any package name that doesn't exist at all (a likely LLM-hallucinated dependency an attacker may have pre-registered), and separately notes any that exist but were only first published very recently.
directoryrequiredCheck a single package name against the real npm or PyPI registry
namerequiredecosystemrequiredAuto-detect and check both npm and pip manifests (package.json, requirements.txt, pyproject.toml) in a directory against their real registries
directoryrequired90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
Claude ──► slopsquat-scanner ──► registry.npmjs.org / pypi.org │ ├─ dependency_not_found (name isn't published anywhere — critical) └─ dependency_recently_published (exists, but published <30 days ago — low/informational){ "mcpServers": { "guardbee-slopsquat-scanner": { "command": "npx", "args": ["-y", "@guardbee/mcp-slopsquat-scanner"] } }}npx @guardbee/mcp-slopsquat-scanner scan . --fail-on=critical --format=sarif > results.sarifslopsquat-scanner: fail-on: critical # critical | low | none include-dev: falsenpm run buildnpm test # 18 unit tests