Skip to main content
Glama

NPMScan

by com.npmscan
OverviewDiscussions(1)Admin

Compare npm packages side-by-side

compare_packages
Read-only

Given 2-5 candidate packages for the same job (e.g. "axios vs got vs node-fetch"), fetches the same registry/popularity/maintenance/vulnerability enrichment get_package computes for each one in parallel and returns a structured side-by-side plus a deterministic, reasoned pick. Each candidate gets downloads + trend, popularityTier/maintenanceTier, GitHub stars, TypeScript support, license, deprecated status, latest-version vulnerability status, a lightweight installScriptRisk signal (scans lifecycle script command strings for known red flags — does NOT fetch the tarball; call analyze_install_script on a specific candidate for that deeper scan), and installSize (the candidate's own dist.unpackedSize plus a transitive rollup — summed dist.unpackedSize across its resolved dependency tree, walked up to depth 2 / 60 nodes per candidate; installSize.transitive.truncated/sizeUnknownCount flag when that sum is partial rather than pretending it's exact — call analyze_transitive_dependencies on a specific candidate for the full graph). differentiators names which candidates stand out on each dimension (most downloads, only ones with TS types, which are deprecated/vulnerable/flagged as a typosquat/install-script risk, smallest/largest install size). recommendation.pick is chosen deterministically from a weighted score (popularity, maintenance, deprecation, vulnerabilities, typosquat flag, install-script risk, TS support, GitHub stars — install size is reported but not scored) — never a deprecated or typosquat-flagged candidate — with rationale explaining why and confidence reflecting how close the top two scored. If a candidate's OSV.dev vulnerability check itself failed (network/timeout/upstream outage), isLatestVersionVulnerable comes back false only because the field has to be a boolean — vulnerabilityCheckFailed:true is the real signal there, and means that candidate's safe/not-safe answer is unknown, not confirmed clean. A name that can't be resolved (typo, unpublished, malformed) still appears in candidates with found:false and resolutionError set rather than failing the whole call; duplicate names in the input are rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packagesYes2-5 exact npm package names to compare, e.g. ["axios", "got", "node-fetch"].

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
candidatesYes
recommendationYes
differentiatorsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / candidates / items / properties / vulnerabilityCheckFailed
      Added value: +{
+  "type": "boolean"
+}
    • changedOutput schema / properties / candidates / items / required
      Previous value: -[
-  "name",
-  "found",
-  "resolutionError",
-  "npmscanUrl",
-  "description",
-  "license",
-  "latestVersion",
-  "deprecated",
-  "weeklyDownloads",
-  "downloadTrend",
-  "githubStars",
-  "hasBuiltInTypes",
-  "daysSinceLastPublish",
-  "popularityTier",
-  "maintenanceTier",
-  "maintenanceSummary",
-  "possibleTyposquatOf",
-  "isLatestVersionVulnerable",
-  "highestSeverity",
-  "vulnerabilityCount",
-  "installScriptRisk",
-  "installSize",
-  "score"
-]New value: +[
+  "name",
+  "found",
+  "resolutionError",
+  "npmscanUrl",
+  "description",
+  "license",
+  "latestVersion",
+  "deprecated",
+  "weeklyDownloads",
+  "downloadTrend",
+  "githubStars",
+  "hasBuiltInTypes",
+  "daysSinceLastPublish",
+  "popularityTier",
+  "maintenanceTier",
+  "maintenanceSummary",
+  "possibleTyposquatOf",
+  "isLatestVersionVulnerable",
+  "vulnerabilityCheckFailed",
+  "highestSeverity",
+  "vulnerabilityCount",
+  "installScriptRisk",
+  "installSize",
+  "score"
+]
  2. Changed5 schema fields changed
    • addedOutput schema / properties / candidates / items / properties / installSize
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "transitive": {
+          "additionalProperties": false,
+          "properties": {
+            "sizeUnknownCount": {
+              "type": "number"
+            },
+            "transitiveDependencyCount": {
+              "type": "number"
+            },
+            "transitiveUnpackedSize": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "truncated": {
+              "type": "boolean"
+            }
+          },
+          "required": [
+            "transitiveUnpackedSize",
+            "transitiveDependencyCount",
+            "sizeUnknownCount",
+            "truncated"
+          ],
+          "type": "object"
+        },
+        "unpackedSize": {
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "unpackedSize",
+        "transitive"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • changedOutput schema / properties / candidates / items / required
      Previous value: -[
-  "name",
-  "found",
-  "resolutionError",
-  "npmscanUrl",
-  "description",
-  "license",
-  "latestVersion",
-  "deprecated",
-  "weeklyDownloads",
-  "downloadTrend",
-  "githubStars",
-  "hasBuiltInTypes",
-  "daysSinceLastPublish",
-  "popularityTier",
-  "maintenanceTier",
-  "maintenanceSummary",
-  "possibleTyposquatOf",
-  "isLatestVersionVulnerable",
-  "highestSeverity",
-  "vulnerabilityCount",
-  "installScriptRisk",
-  "score"
-]New value: +[
+  "name",
+  "found",
+  "resolutionError",
+  "npmscanUrl",
+  "description",
+  "license",
+  "latestVersion",
+  "deprecated",
+  "weeklyDownloads",
+  "downloadTrend",
+  "githubStars",
+  "hasBuiltInTypes",
+  "daysSinceLastPublish",
+  "popularityTier",
+  "maintenanceTier",
+  "maintenanceSummary",
+  "possibleTyposquatOf",
+  "isLatestVersionVulnerable",
+  "highestSeverity",
+  "vulnerabilityCount",
+  "installScriptRisk",
+  "installSize",
+  "score"
+]
    • addedOutput schema / properties / differentiators / properties / largestInstallSize
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / differentiators / properties / smallestInstallSize
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / properties / differentiators / required
      Previous value: -[
-  "mostDownloads",
-  "mostGithubStars",
-  "hasTypeScriptSupport",
-  "hasKnownVulnerabilities",
-  "deprecated",
-  "possibleTyposquat",
-  "installScriptRiskFlagged"
-]New value: +[
+  "mostDownloads",
+  "mostGithubStars",
+  "hasTypeScriptSupport",
+  "hasKnownVulnerabilities",
+  "deprecated",
+  "possibleTyposquat",
+  "installScriptRiskFlagged",
+  "smallestInstallSize",
+  "largestInstallSize"
+]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral detail: parallel fetching, deterministic pick that never selects deprecated or typosquat-flagged candidates, the vulnerabilityCheckFailed fallback semantics, truncation behavior for transitive install size (with truncated/sizeUnknownCount flags), and the 'found:false plus resolutionError' handling for unresolved names. These extend far beyond the annotation surface and align with the openWorldHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and selection context, and every sentence carries information — no filler. However, it is a single dense paragraph with many nested clauses and technical caveats, which could hamper quick skimming. Breaking it into bullets would improve scannability without losing content. The density is justified by the tool's complexity, but the structure is not optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's core behavior, output highlights (downloads, tiers, install size, differentiators, recommendation), error handling (vulnerability check failures, unresolved names), and boundary conditions (duplicate rejection, truncation). Given the presence of an output schema and only one well-described parameter, an agent has everything needed to invoke it correctly. It is complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that the packages should be candidates for the same job, that duplicate names are rejected, and how unresolved names are represented (found:false with resolutionError). It also links the packages parameter to the parallel enrichment and decision logic. Slightly more could be said about the exact format of names, but the description already meaningfully augments the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Given 2-5 candidate packages for the same job ... fetches the same ... enrichment ... and returns a structured side-by-side plus a deterministic, reasoned pick.' It clearly distinguishes from siblings by referencing get_package for the underlying enrichment and explicitly naming deeper alternatives (analyze_install_script, analyze_transitive_dependencies). An agent can understand the tool's role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool: 'Given 2-5 candidate packages for the same job.' It also provides alternatives: 'call analyze_install_script on a specific candidate for that deeper scan' and 'call analyze_transitive_dependencies on a specific candidate for the full graph.' Additional usage rules like duplicate name rejection and unresolved name handling are clearly stated, making the boundary between this tool and its siblings unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All NPMScan toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources