原型 · 预览版:收录官方注册中心里的全部服务器,每 30 分钟同步一次。评价和账户功能将在后续阶段推出。
PopNx MCP为使用 AI 的人准备的 MCP 服务器 · 用大白话讲清楚

Import Guardian

作者:Baneado98版本 0.3.0i★ –i在你的电脑上运行
注册名称io.github.Baneado98/import-guardian

安装

概览

作者提供的说明(英文原文)

Catch AI-hallucinated (slopsquatted) npm imports in generated code before npm install.

PopNx MCP 的三大支柱

这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。

它能帮你做什么

我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。

  • 连接方式: 在你的电脑上运行
  • 传输方式: stdio
  • 分类: 开发者工具

安装

选择你使用的 AI 应用,然后复制设置。

安装之前

  • 基础检查:1 项中通过 1 项
  • 在你的电脑上运行,拥有你的用户账户的权限(文件、网络、应用)。
  • 注册中心没有列出需要填写的密钥。

你需要

  • npm已安装 Node.js(用于 npx 命令)

你用的是哪个应用?

在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。

打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json

{
  "mcpServers": {
    "import-guardian": {
      "command": "npx",
      "args": [
        "-y",
        "import-guardian-mcp"
      ]
    }
  }
}

在终端中运行这条命令

claude mcp add import-guardian -- npx -y import-guardian-mcp

在 Cursor 中打开

或者自己复制设置

粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json

{
  "mcpServers": {
    "import-guardian": {
      "command": "npx",
      "args": [
        "-y",
        "import-guardian-mcp"
      ]
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

在 VS Code 中打开

或者自己复制设置

粘贴到项目中的 .vscode/mcp.json

{
  "servers": {
    "import-guardian": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "import-guardian-mcp"
      ]
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。

你的选择通过 Cookie 保存在这台设备上,无需账户。

这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。

它能做什么

它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。

基础检查i

我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月9日

  • ✓ 通过

    作者与仓库一致

    注册名称已通过 GitHub 账户 Baneado98 验证,该账户拥有此仓库

  • … 尚未检查

    仍在维护

    我们还没有从 GitHub 读取这个仓库

  • … 尚未检查

    有许可证

    我们还没有从 GitHub 读取这个仓库

  • – 不适用

    端点有响应

    它在你的电脑上运行,没有互联网端点

  • – 不适用

    使用 OAuth 登录

    在你的电脑上运行,改用本地设置

  • … 尚未检查

    工具描述中没有隐藏指令

    它在你的电脑上运行;我们只能读取互联网端点的工具列表

与“开发者工具”中的其他服务器比较i

  • 星标数多于此分类中其他 5565 个服务器的 0%
  • 发布到注册中心的时间比此分类中其他 5565 个服务器的 20% 更新
  • 基础检查结果等于或优于此分类中其他 5565 个服务器的 100%

与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。

常见问题

Import Guardian 安全吗?

它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。

它需要哪些密钥或代码?

注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。

它在我的电脑上运行还是在云端?

它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。

它还在维护吗?

GitHub 仓库最后更新于–,最新版本(0.3.0)于5个月前进入注册中心。

哪些应用可以使用它?

支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js。

有什么可以替代它?

同一分类中有:GitHub, Desktop Commander, Cloudflare MCP

替代选择

同一分类中其他作者的服务器,按星标数排序。

如何看卡片:↓ 每周下载量i★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i

GitHub

Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.

作者:github广泛使用★ 3.4万5天前更新

电脑或云端

Desktop Commander

MCP server for terminal commands, file operations, and process management

作者:wonderwhy-er广泛使用↓ 71万/周★ 1万18天前更新

在你的电脑上运行

Cloudflare MCP

Cloudflare MCP servers

作者:cloudflare广泛使用★ 444614个月前更新

在云端运行✓ mcp.cloudflare.com

作者的 README

打开 README

按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。

import-guardian 🪝

Catch AI-hallucinated (slopsquatted) npm imports in generated code — _before_ you run `npm install`.

An LLM just wrote some code. It might import a package that doesn't exist — a name the model confidently hallucinated. Attackers register exactly those names and ship malware. This is slopsquatting, and in 2026 it's one of the fastest-growing supply-chain attacks: code generators have been observed referencing 205,000+ unique non-existent package names, and real hallucinated packages (react-codeshift, a fake huggingface-cli with 30k+ downloads) have already shown up in the wild.

import-guardian reads the generated code, extracts every npm package it imports, and tells you which ones are real — so an agent never installs a name its own model invented.

It's part of the guardian set: npm-guardian audits a package you've _already chosen_ for CVEs and malicious behaviour, license-guardian audits the _licenses_ of your dependencies (GPL/AGPL/BUSL traps) before you ship, and lockfile-guardian audits the resolved package-lock.json for integrity tampering and risky install scripts. import-guardian works one step earlier than all of them, at the moment the code — and its dependency names — are generated.

What it catches

👻 Hallucinatedimports of packages that do not exist on npm — the model invented the name. Returns BLOCK with a "did you mean" to the closest real package.
🪤 Fresh squatspackages that _do_ exist but were published days ago, have no source repo, near-zero downloads, or are a 1–2 edit typo of a popular library. Returns REVIEW.
🧩 Import-awareresolves import x from "@scope/pkg/sub" → @scope/pkg, lodash/fp → lodash; skips Node built-ins (fs, node:path) and local paths. Plain regex, no AST, zero runtime deps beyond the MCP SDK.

Verdicts: 🟢 CLEAN · 🟠 REVIEW · 🔴 BLOCK.

Use it as an MCP server (free)

{

"mcpServers": { "import-guardian": { "command": "npx", "args": ["-y", "import-guardian-mcp"] } } }

Tools:

  • `scan_code_imports` — give it a block of generated JS/TS; it extracts and checks every npm import. _Run this on code you just generated, before its install command._
  • `check_packages` — verify an explicit list of package names.
  • `verify_package` — deep-check a single package name (existence, age, versions, repo, weekly downloads, edit distance to popular packages).
  • `audit_lockfile` 🔒 _(premium)_ — the deep one. Give it a lockfile from npm (package-lock.json), yarn (yarn.lock), pnpm (pnpm-lock.yaml), PyPI (requirements.txt / poetry.lock / Pipfile.lock) or Go (go.mod / go.sum) and it resolves the whole transitive tree and audits every package for dependency confusion, transitive typosquats / homoglyph clones, maintainer-takeover fingerprints, nonexistent pins, and install-script risk. See below.

Deep lockfile audit (premium) 🔒

scan_code_imports looks at the handful of imports you can *see*. audit_lockfile looks at the hundreds you can't — the fully resolved dependency graph in your lockfile — and finds the supply-chain attacks an LLM cannot reason about from source alone:

🎯 Dependency confusiona package the lockfile resolves from a private / internal registry whose name is unclaimed on the public index — an attacker can publish that exact name publicly and shadow it. The single highest-impact supply-chain bug, and impossible to detect without the resolved lockfile + a live public-registry cross-check. On PyPI it's sharper still: pip install --extra-index-url merges your private index with public PyPI and installs the highest version from either (the 2021 attack that hit Microsoft / Apple / Tesla). Returns critical.
🪞 Transitive typosquatshomoglyph/Unicode-confusable clones (rеact with a Cyrillic *e*), transpositions (axois→axios), and registry-specific squats (PyPI python3-dateutil vs python-dateutil, normalized per PEP 503) across the entire tree — matched against a large per-ecosystem corpus of high-traffic packages.
🕳️ Maintainer takeoverthe fingerprint of a compromised maintainer: a dormant package suddenly republished, a sole-maintainer project, or a rapid republish burst — the pattern behind event-stream, ua-parser-js, node-ipc and PyPI's ctx hijack.
💉 Install-script version-diffingthe sharpest injection signal: a package whose newest release ADDED a postinstall/preinstall/install/prepare hook that the previous release did not have. A previously-clean dependency that suddenly gains code-execution-on-install is exactly how event-stream and ua-parser-js shipped — caught by diffing the two releases' metadata on the live registry. Returns critical, and tells you the last clean version to pin.
🔬 Install-script PAYLOAD analysisgoes past *whether* a hook exists to *what it does*: downloads the package tarball, gunzip+untars it in-memory (no deps), resolves the lifecycle command to its entry file, and statically analyzes the actual code for malware behavior — network egress, credential/env exfil, child-process exec, download-and-run, obfuscation. An obfuscation-resistant AST/token analyzer decodes \x/\u/octal escapes and folds split-string concatenation, so a sink hidden as require("child_pro"+"cess") or global["ev"+"al"](…) is still caught. The payload lives inside a binary artifact the buyer's agent never fetches — that's the access+compute moat.
🐍 PyPI sdist `setup.py` payload analysisthe PyPI analogue of the npm tarball pass, and the sharpest PyPI surface: a source distribution runs setup.py — arbitrary Python — at `pip install` time, before any of your code. We download the sdist (anti-DoS capped), untar it in-memory, and statically analyze setup.py / setup.cfg / pyproject.toml for the stealer/loader pattern — os.environ exfil, os.system/subprocess exec, .pypirc/AWS/SSH credential theft, urllib/requests egress, exec/eval/__import__ obfuscation, download-and-run, and a non-standard build backend. A Python AST de-obfuscator decodes \x/\u/octal escapes and folds split + implicit-adjacent strings, so getattr(__import__("o"+"s"),"sys"+"tem")(…) is still resolved. The ctx / jeIlyfish / colourama attack class — caught from an artifact the buyer's agent never fetches. **BLOCK is gated on the malware *combination* (exfil/download-exec/packed-loader), so a legitimate C/Cython build that merely shells out to a compiler is reported as an informational note, not** a false-positive block.
🦠 Known-malware / known-vuln (live OSV cross-reference)every resolved package is cross-referenced — at its exact pinned version — against the live [OSV.dev](https://osv.dev) advisory database (which ingests the OpenSSF Malicious Packages feed as MAL-* plus GitHub/PyPI/Go/crates/Maven/Packagist advisories). If the version your lockfile pins is documented malware (e.g. event-stream@3.3.6, ctx@0.1.2), that's a critical / BLOCK — the strongest possible signal. The mapping is version-specific: event-stream@3.3.6 is malware, 3.3.4 is clean, and only a live database query can tell them apart. This is a different *kind* of moat from the static passes above — the buyer's model doesn't hold the advisory corpus and can't resolve version↔advisory. Queries are batched, cached (TTL), concurrency-capped, and degrade clean if OSV is unreachable (it never turns a clean package into a false positive).
🏗️ Local build-backend follow-hop (PyPI)when pyproject.toml declares a **non-standard build backend that ships *inside* the sdist (`backend-path = ["."]`), the package runs its own code as the PEP 517 backend at every build/install. We resolve that module to its file in the sdist and analyze its real source** (and follow setup.py's local imports one hop), instead of merely flagging the backend name — closing the gap where a payload hides one indirection away from setup.py.
🔀 Go `replace` hijacka replace … => host/path in go.mod pointing at an external host, live-verified against the Go module proxy. If the replacement doesn't resolve (a private / attacker host), the code your build actually compiles isn't the module you audited or anything go.sum can vouch for.
💣 Install-script & provenance riskpackages in the resolved tree that run install scripts, brand-new pins, missing repos, and near-zero real downloads (verified against npm / pypistats / crates.io).

Seven ecosystems. The same resolved-graph engine runs over npm / yarn / pnpm, PyPI (requirements.txt, poetry.lock, Pipfile.lock), Go modules (go.mod, go.sum), Rust / Cargo (Cargo.lock, Cargo.toml), Java (Maven pom.xml, Gradle build.gradle / .kts / gradle.lockfile) and PHP / Composer (composer.json, composer.lock) — each cross-checked against its own public index (npm registry, PyPI, the Go module proxy, crates.io, Maven Central, Packagist). On crates.io the matcher knows the -/_ equivalence (rustdecimal vs rust_decimal); on Maven an internal groupId:artifactId unclaimed on Central is the dependency-confusion target; on Composer an internal vendor/package unregistered on Packagist while a private repo is merged with the public index is the confusion target, and a Packagist-abandoned package is flagged as a takeover risk. Large lockfiles are bounded: direct + private-source packages are always live-checked first, then transitive up to a cap, so one call never fans out to tens of thousands of requests.

POST /pro/audit   { "lockfile": "<contents of package-lock.json>", "filename": "package-lock.json" }

Pay per call via x402 (USDC on Base) or a prepaid Stripe key. The free POST /audit returns the verdict and issue counts by severity, but withholds which packages are affected and why — that's the paid report. This deep engine runs server-side only and is never shipped in the npm package.

Example
scan_code_imports({ code: 'import shift from "react-codeshift";\nimport React from "react";' })

🟠 REVIEW — 1 referenced package(s) look risky. 🟠 react-codeshift (risk 57/100) • No source repository linked. • Only 1 published version. • Only 3 downloads in the last week despite being 158 days old. 🟢 react (ok) — established package.

Free HTTP API

POST /scan        { "code": "import x from 'reqeusts'\nimport y from 'lodash'" }

GET /verify?name=express

Hosted at https://import-guardian.vercel.app · try /verify?name=express vs /verify?name=reqeusts.

Pay-per-call (x402)

The /pro/* routes are gated by x402. Your agent pays $0.02 USDC per call automatically — no sign-up, no API key. Payment settles on-chain (USDC on Base). The server holds no private key; it only declares a public receiving address.

POST /pro/scan    { "code": "…" }   # 402 → pay → result, no rate limit

How it works (and its limits)

  • Existence + freshness come straight from the live npm registry (registry.npmjs.org) and the download-stats API — these are facts, not guesses, which is the moat: an agent can't reliably know on its own whether a name it generated is real and trusted.
  • "Did you mean" uses Levenshtein distance against a curated list of high-impact packages attackers impersonate.
  • It does not execute or install

只显示了开头部分;其余内容请在仓库中阅读

问 PopNx