NPMScan

Audit a GitHub repository's npm dependencies

audit_github_repository

Read-only

Given a GitHub repository URL, fetches its package.json (and, if present, a pnpm-lock.yaml/package-lock.json/yarn.lock — first one found wins, in that priority order) straight from the repo's default branch and runs the same vulnerability, license-compliance, install-script, and ownership-risk pipelines batch_query_vulnerabilities/check_license_compliance/analyze_install_script/check_maintainer_changes/check_package_provenance expose individually, in one call — no copy-pasting file contents required. A monorepo (package.json#workspaces, Yarn's {packages:[...]} form, or pnpm-workspace.yaml) is detected automatically: pnpm-lock.yaml and yarn.lock already record every workspace member's dependencies directly, and for package.json-only or package-lock.json repos this additionally lists the repo's file tree, resolves the declared glob patterns to member directories, and merges each member's dependencies into the audit (capped at 50 member packages) — see isMonorepo/workspacePatterns/workspacePackageCount/workspaceNote in the result. Every direct dependency (up to 100 per call, across the root and any merged workspace members) gets: an OSV.dev vulnerability check, a license-compliance verdict against the given policy (same default as check_license_compliance: only copyleft/network-copyleft/proprietary are violations unless you pass one), and a tarball-free install-script risk signal (installScriptScanScope: 'lifecycle-scripts-only'). Up to 10 of the packages that actually declare a lifecycle script — prioritized by already-vulnerable, then possible-typosquat, then whatever's left — additionally get the full tarball-fetching deep scan analyze_install_script itself runs (installScriptScanScope: 'deep-tarball-scan', with a populated installScriptFindings array); any remaining flagged packages past that cap keep the lighter signal only, noted in deepScanNote. Any package that comes back vulnerable at high/critical severity, a possible typosquat, or deprecated (ownershipRiskEligible) additionally gets check_maintainer_changes and check_package_provenance run against it — up to 5 such packages per call (ownershipRiskChecked), prioritized the same way as the deep install-script scan, populating maintainerRiskTier/maintainerFindings and provenanceRiskTier/provenanceFindings; remaining eligible packages past that cap are named in ownershipCheckNote. This is the most expensive tool in the suite (a repo lookup, a handful of file fetches, up to 100 registry doc fetches, one OSV batch call, up to 10 tarball fetches, up to 5 packages each getting a maintainer-history check plus a provenance check — the latter alone can fan out to ~8 more registry fetches on its own — and, for a monorepo needing enumeration, one file-tree listing plus up to 50 more manifest fetches) — don't call it in a loop across many repos.

Input Schema

TableJSON Schema

Name	Required	Description
`ref`	No	Branch, tag, or commit SHA to audit. Omit to use the repository's default branch.
`url`	Yes	GitHub repository URL, e.g. "https://github.com/owner/repo".
`policy`	No	License allow/deny policy, same shape as check_license_compliance. Omit for the default policy (only copyleft/network-copyleft/proprietary are violations).
`includeDevDependencies`	No	Include package.json devDependencies in the audit. Default false. Ignored when a lockfile is used instead (its own format decides direct-dependency scope), and yarn.lock can never distinguish dev from production dependencies regardless of this flag.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ref`	Yes
`owner`	Yes
`policy`	Yes
`summary`	Yes
`findings`	Yes
`repoName`	Yes
`warnings`	Yes
`isMonorepo`	Yes
`inputFormat`	Yes
`deepScanNote`	Yes
`lockfilePath`	Yes
`manifestPath`	Yes
`totalPackages`	Yes
`workspaceNote`	Yes
`truncationNote`	Yes
`deepScannedCount`	Yes
`overflowPackages`	Yes
`defaultBranchUsed`	Yes
`workspacePatterns`	Yes
`ownershipCheckNote`	Yes
`licenseViolationCount`	Yes
`ownershipCheckedCount`	Yes
`workspacePackageCount`	Yes
`vulnerablePackageCount`	Yes
`installScriptFlaggedCount`	Yes
`ownershipRiskFlaggedCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed12 schema fields changedSep 4, 2026

addedOutput schema / properties / findings / items / properties / maintainerFindings

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "$ref": "#/properties/findings/items/properties/installScriptFindings/anyOf/0/items"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / findings / items / properties / maintainerRiskTier

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/properties/findings/items/properties/installScriptRiskTier/anyOf/0"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / findings / items / properties / ownershipRiskChecked
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / findings / items / properties / ownershipRiskEligible
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / findings / items / properties / ownershipRiskReason

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "critical-or-high-severity-vulnerability",
+        "possible-typosquat",
+        "deprecated"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / findings / items / properties / provenanceFindings

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "$ref": "#/properties/findings/items/properties/installScriptFindings/anyOf/0/items"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / findings / items / properties / provenanceRiskTier

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/properties/findings/items/properties/installScriptRiskTier/anyOf/0"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / findings / items / required

Previous value: -[
-  "name",
-  "requestedVersion",
-  "resolvedVersion",
-  "npmscanUrl",
-  "deprecated",
-  "possibleTyposquatOf",
-  "isVulnerable",
-  "highestSeverity",
-  "vulnerabilities",
-  "rawLicense",
-  "licenseCategory",
-  "isLicenseCompliant",
-  "licenseNeedsReview",
-  "licenseViolation",
-  "hasLifecycleScripts",
-  "installScriptRiskTier",
-  "installScriptScore",
-  "installScriptScanScope",
-  "installScriptFindings",
-  "resolutionError"
-]New value: +[
+  "name",
+  "requestedVersion",
+  "resolvedVersion",
+  "npmscanUrl",
+  "deprecated",
+  "possibleTyposquatOf",
+  "isVulnerable",
+  "highestSeverity",
+  "vulnerabilities",
+  "rawLicense",
+  "licenseCategory",
+  "isLicenseCompliant",
+  "licenseNeedsReview",
+  "licenseViolation",
+  "hasLifecycleScripts",
+  "installScriptRiskTier",
+  "installScriptScore",
+  "installScriptScanScope",
+  "installScriptFindings",
+  "resolutionError",
+  "ownershipRiskEligible",
+  "ownershipRiskReason",
+  "ownershipRiskChecked",
+  "maintainerRiskTier",
+  "maintainerFindings",
+  "provenanceRiskTier",
+  "provenanceFindings"
+]

addedOutput schema / properties / ownershipCheckNote

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / ownershipCheckedCount
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / ownershipRiskFlaggedCount
```
Added value: +{
+  "type": "number"
+}
```

changedOutput schema / required

Previous value: -[
-  "summary",
-  "owner",
-  "repoName",
-  "ref",
-  "defaultBranchUsed",
-  "manifestPath",
-  "lockfilePath",
-  "inputFormat",
-  "isMonorepo",
-  "workspacePatterns",
-  "workspacePackageCount",
-  "workspaceNote",
-  "policy",
-  "findings",
-  "overflowPackages",
-  "totalPackages",
-  "vulnerablePackageCount",
-  "licenseViolationCount",
-  "installScriptFlaggedCount",
-  "deepScannedCount",
-  "warnings",
-  "truncationNote",
-  "deepScanNote"
-]New value: +[
+  "summary",
+  "owner",
+  "repoName",
+  "ref",
+  "defaultBranchUsed",
+  "manifestPath",
+  "lockfilePath",
+  "inputFormat",
+  "isMonorepo",
+  "workspacePatterns",
+  "workspacePackageCount",
+  "workspaceNote",
+  "policy",
+  "findings",
+  "overflowPackages",
+  "totalPackages",
+  "vulnerablePackageCount",
+  "licenseViolationCount",
+  "installScriptFlaggedCount",
+  "deepScannedCount",
+  "ownershipCheckedCount",
+  "ownershipRiskFlaggedCount",
+  "warnings",
+  "truncationNote",
+  "deepScanNote",
+  "ownershipCheckNote"
+]

Changed5 schema fields changedSep 4, 2026

addedOutput schema / properties / isMonorepo
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / workspaceNote

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / workspacePackageCount
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / workspacePatterns

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "summary",
-  "owner",
-  "repoName",
-  "ref",
-  "defaultBranchUsed",
-  "manifestPath",
-  "lockfilePath",
-  "inputFormat",
-  "policy",
-  "findings",
-  "overflowPackages",
-  "totalPackages",
-  "vulnerablePackageCount",
-  "licenseViolationCount",
-  "installScriptFlaggedCount",
-  "deepScannedCount",
-  "warnings",
-  "truncationNote",
-  "deepScanNote"
-]New value: +[
+  "summary",
+  "owner",
+  "repoName",
+  "ref",
+  "defaultBranchUsed",
+  "manifestPath",
+  "lockfilePath",
+  "inputFormat",
+  "isMonorepo",
+  "workspacePatterns",
+  "workspacePackageCount",
+  "workspaceNote",
+  "policy",
+  "findings",
+  "overflowPackages",
+  "totalPackages",
+  "vulnerablePackageCount",
+  "licenseViolationCount",
+  "installScriptFlaggedCount",
+  "deepScannedCount",
+  "warnings",
+  "truncationNote",
+  "deepScanNote"
+]

AddedSep 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description goes far beyond the readOnly/openWorld annotations by detailing lockfile priority, workspace detection, dependency caps, deep-scan prioritization, ownership-check limits, and the large number of downstream network fetches. This is exactly the behavioral context an agent needs before invoking an expensive open-world read tool.

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 long, but the tool genuinely has many important caps, priority rules, and cost characteristics that would be dangerous to omit. It is front-loaded with the core action and resource cost, but the dense single-paragraph format with nested clauses could be significantly easier to scan.

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 full runtime behavior: file-fetch strategy, monorepo handling, dependency caps, scan priorities, ownership-risk eligibility, and cost profile. Combined with an output schema, the agent has everything needed to invoke the tool correctly and set expectations about its price.

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

Parameters3/5

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

All four parameters are already documented in the input schema with 100% coverage, so the description does not need to compensate. It adds general behavioral context around policy defaults and lockfile scope, but most of that is either already in the schema or is not parameter-specific.

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 concrete verb and resource: given a GitHub repository URL, fetch its dependency manifests and run a complete npm audit in one call. It explicitly names the sibling pipelines it aggregates, so an agent can distinguish this combined audit tool from the individual check tools.

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

Usage Guidelines4/5

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

It clearly states that this is the most expensive tool in the suite and warns not to call it in a loop across many repositories. It also names the individual sibling tools it composes, but it never explicitly tells the agent when to choose those cheaper alternatives instead of this aggregate.

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

All NPMScan tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

Most tools target a distinct part of the supply-chain lifecycle, and the detailed descriptions include explicit cross-references that reduce misselection. The main ambiguity is among the vulnerability-lookup tools—especially get_latest_advisories and get_cve, which both accept CVE IDs, and query_vulnerabilities versus batch_query_vulnerabilities, which differ mainly in input shape.

Naming Consistency5/5

Every tool name uses lowercase snake_case with a leading imperative verb or verb phrase: analyze_, audit_, batch_query_, check_, compare_, diff_, get_, prioritize_, query_, search_, and suggest_. The check_* tools form a consistent sub-family, and there are no camelCase or noun-only strays.

Tool Count4/5

18 tools is on the high side, so the server feels slightly heavy rather than lean. However, the domain is broad enough that each tool occupies a meaningful workflow step—metadata lookup, vulnerability querying, transitive analysis, license/maintainer/provenance checks, repo auditing, diffing, and remediation—so the count is still reasonable for a comprehensive npm security server.

Completeness5/5

The surface covers the full npm supply-chain audit workflow: discovery, exact-version and lockfile vulnerability checks, transitive dependency resolution, install-script deep scans, license compliance, maintainer and provenance history, repo-level audits, dependency diffs, remediation prioritization, and alternative suggestions. There are no obvious dead ends, and the tools consistently point to natural follow-up actions.

Resources

Need Help?