This server verifies npm packages before you install, import, or recommend them, flagging hallucinated, slopsquatted, deprecated, abandoned, or otherwise risky dependencies.
check_package — verify one exact npm package name; returns existence and flags impersonation, install-time scripts, deprecation, abandonment, and missing repository/source.
check_dependencies — verify up to 50 package names at once, sorted worst-first, useful before writing a package.json or running an install command.
Verdicts include SAFE, CAUTION, DANGER, HALLUCINATED, and UNKNOWN, each with supporting evidence.
Network failures return UNKNOWN, never SAFE, so a degraded connection cannot silently bypass the safety check.
Provides tools to verify npm package trustworthiness before installation, checking registry existence, security placeholders, impersonation, install scripts, deprecation, adoption, and maintenance status.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pkgtruth Check if unused-imports is a hallucinated package before adding it to my project."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Ground truth about npm packages, for AI coding agents and CI.
Your agent just wrote npm install unused-imports. That package is not the
linter plugin it meant. It is a name an attacker registered because models
kept inventing it — and npm has since replaced it with a security placeholder.
pkgtruth catches that before it reaches your lockfile.
Large language models invent package names. Measured across models, 19.7% of generated package names were hallucinated, and when researchers re-ran the prompts, 43% of those names came back every single time.
That reproducibility is the whole attack. An attacker does not need to compromise a maintainer, poison a build server, or find a vulnerability. They watch what models invent, register the name, and wait. The technique is called slopsquatting, and it is already happening in the wild.
The standing security advice is that agents with package-management
capabilities should not install anything without a review gate. pkgtruth is
that gate, in a form an agent can call on its own.
Related MCP server: npm-guardian
Two names a model plausibly produces, both live on npm today:
Name | What it is | Weekly installs | The real one |
|
| 10 |
|
| Deprecated since 2022, "use the socket.io package instead" | 1,486 |
|
types-node is what you get when a model drops the scope from @types/node.
npm removed it for malicious code in December 2024 and it is still installed
ten times a week.
socket-io is not malicious — it is an abandoned package with a confusable
name. That it takes 1,486 installs a week anyway is the point: a dot and a
hyphen are enough.
npx pkgtruth check types-node socket-io{
"mcpServers": {
"pkgtruth": {
"command": "npx",
"args": ["-y", "pkgtruth"]
}
}
}Two tools become available:
Tool | Use it when |
| About to add, import, or recommend one dependency |
| About to write a |
npx pkgtruth check express unused-imports
npx pkgtruth scan .scan reads every dependency in a package.json and exits non-zero when
something is blocking, so it drops straight into CI:
- name: Block hallucinated and slopsquatted dependencies
run: npx pkgtruth scan . --fail-on dangerSignal | Meaning |
Not in registry | The name is fabricated. Nothing to install. |
npm security placeholder | npm removed malicious code published under this name. |
Impersonates a popular package | A near-identical name with a fraction of the adoption. |
Install-time scripts |
|
Deprecated | Upstream says stop using it. |
Very new / almost no adoption | Days old with single-digit installs. |
No repository | No source to audit. |
Unmaintained | No release in years. |
Verdicts are SAFE, CAUTION, DANGER, HALLUCINATED, or UNKNOWN. Every
one arrives with the evidence behind it — an agent should never have to take
"DANGER" on faith, and neither should you.
Network failures never open the gate. If the registry is unreachable, the
verdict is UNKNOWN, never SAFE. A degraded network must not silently turn
a security check into a no-op.
Popular packages are not flagged. Checked against a real 18-dependency project, zero false positives. A gate that cries wolf gets switched off.
No build step. Two direct dependencies — the MCP SDK and zod, both only
needed for the server. npx pkgtruth starts immediately.
Read these before trusting it:
npm only. PyPI, crates.io, and Go modules are not covered yet.
Registry metadata only. It does not analyze package source code, so a legitimate-looking package with a malicious payload can still pass.
Not a replacement for npm audit or Snyk. Those find known CVEs in code
you already trust. pkgtruth asks the earlier question: should this package
be here at all?
New legitimate packages will get CAUTION. That is deliberate. Newness
genuinely is a risk signal; use --fail-on danger so it does not block.
--json Machine-readable output
--fail-on <level> danger (default) | caution--fail-on caution also blocks packages that could not be verified at all,
since "we could not check" is not a pass.
Exit codes: 0 clean, 1 blocking packages found, 2 usage or runtime error.
Variable | Default | Purpose |
|
| Per-request timeout |
|
| Retries for 429/5xx/network errors |
| per-host | Override request pacing |
| npm | Alternate registry |
| npm | Alternate downloads API |
|
| Where adoption figures are cached |
| 6 hours | How long a cached figure stays usable |
| unset | Set to |
Adoption figures come from npm's downloads API, which throttles bursts and
cannot batch scoped names — a project with several @scope/pkg dependencies
would spend its whole budget on every scan.
Three things keep that in check: the bulk endpoint resolves all unscoped names in one request, requests to that host are paced serially, and figures are cached on disk for six hours. Weekly download counts move slowly, so a six-hour-old number is no less true.
A warm scan of ~18 dependencies takes about 1.4 seconds. A cold one after
heavy use may return UNKNOWN for some packages — that is the intended
failure mode. A throttled lookup never becomes SAFE; re-run, and the cache
will answer.
Cached figures are keyed by the API they came from, so pointing
PKGTRUTH_DOWNLOADS_API at a private registry never reuses npm's numbers.
Issues and pull requests are welcome at github.com/hxckya/pkgtruth.
Two things make a report especially useful: a legitimate package that gets flagged, and a malicious one that slips through. Both are regression tests waiting to be written.
npm test # offline
npm run test:online # includes live registry checksMIT © hxckya
Verify many npm packages at once — use this before writing a package.json, running an install command, or handing a dependency list to a user. Results are sorted worst-first so anything hallucinated or dangerous surfaces at the top.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Package names to verify (max 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds meaningful behavior by stating that results are sorted worst-first, ensuring hallucinated or dangerous packages surface at the top. It does not describe the response format or side effects, but 'verify' strongly implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core action first, then practical use cases, then the key behavioral nuance about sorting. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides enough context to invoke it correctly: when to use it, what it accepts, and what results look like. It could be more complete by naming check_package as the single-package alternative or describing the result payload, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'names' parameter well. The description reinforces the batch aspect and ties it to dependency-list checks, but it does not add substantially new parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') with a clear resource ('many npm packages at once'), which immediately conveys the tool's batch nature. This distinguishes it from the sibling check_package, which presumably handles a single package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: before writing a package.json, running an install command, or handing a dependency list to a user. It does not explicitly mention the alternative for single-package checks, but the batch-focused phrasing provides clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a single npm package before installing, importing, or recommending it. Returns whether it actually exists, and flags slopsquatting (a low-adoption package impersonating a popular one), install-time scripts, deprecation, and abandonment. Call this whenever you are about to introduce a dependency you have not verified in this session.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact npm package name, e.g. "express" or "@scope/pkg". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and handles it well: it states that the call returns existence and flags specific risk patterns (slopsquatting, install-time scripts, deprecation, abandonment), which implies a read-only verification behavior. It does not disclose network behavior or error handling for invalid package names, but those are minor gaps for a verification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the purpose with an imperative verb and the resource immediately. The second sentence's list of risk flags is compact and useful, and the parenthetical on slopsquatting justifies the niche term. Nothing is redundant, though the list of flags makes it slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description covers what the tool does, what it returns, and when to call it. The absence of an output schema makes the described return values particularly valuable. Edge-case behavior (e.g., result shape for a nonexistent package or network errors) is not addressed, but this is a minor omission for a single-package check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter 'name' is already documented with format and examples ('express' or '@scope/pkg'). The description does not add meaning beyond what the schema provides, so the baseline score of 3 is appropriate. It correctly reinforces the singular scope, but adds no new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verify'), a specific resource ('a single npm package'), and the context ('before installing, importing, or recommending it'). It implicitly distinguishes from its plural sibling check_packages by emphasizing 'single', and it enumerates exactly what the check returns: existence, slopsquatting, install-time scripts, deprecation, and abandonment. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'Call this whenever you are about to introduce a dependency you have not verified in this session.' This is clear when-to-use guidance. However, it does not explicitly state when not to use it or name the alternative (e.g., a batch-check sibling), though the singular/plural naming and the verb make the boundary reasonably obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1check_dependenciescheck_packageThe two tools are clearly distinguished by cardinality: check_package handles a single package while check_dependencies handles multiple. The usage guidance in each description reinforces when to call which, leaving no real ambiguity.
Both tool names follow the exact verb_noun pattern with a shared check_ prefix. This is perfectly consistent and predictable.
Two tools is on the low end of the typical range, but the narrow domain (npm package verification) justifies a small surface. Still, it feels slightly thin for a server that could reasonably expose more granular operations.
The tool set fully covers the stated purpose of verifying packages before install: single-package checks and bulk dependency validation. It also bundles multiple critical checks (existence, slopsquatting, install-time scripts, deprecation, abandonment) into each call, so there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Blocks typosquatted or hallucinated npm/PyPI packages before an AI agent installs them.
Protects AI coding agents from installing malicious open source packages. Every npm and PyPI package is checked against SafeDep’s real-time threat intelligence before installation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hxckya/pkgtruth'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
