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.6/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: it discloses lockfile priority order, monorepo detection behavior, per-call caps (100 dependencies, 50 workspace members, 10 deep scans, 5 ownership checks), prioritization rules, and the cost profile. It also surfaces limitations such as yarn.lock not distinguishing dev from production dependencies.

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 a single dense paragraph, but the opening sentence front-loads the core action and every subsequent clause adds an operationally important constraint or caveat. It is longer than ideal and could benefit from bullet structure, but no sentence is filler given the tool's complexity.

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 detection behavior, caps, fallback outputs, result fields (isMonorepo, workspaceNote, deepScanNote, ownershipCheckNote), cost, and limitations, and an output schema also exists. An agent has everything needed to decide whether to call it and what to expect.

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?

Input-schema coverage is 100%, and the schema already carries detailed descriptions for url, ref, policy, and includeDevDependencies, including defaults and lockfile interactions. The tool description adds broad behavioral constraints like the 100-dependency cap, but it does not materially enrich the meaning of individual parameters beyond 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 names a specific verb and resource: audit a GitHub repository by fetching package manifests and lockfiles and running the vulnerability, license, install-script, and ownership-risk pipelines. It explicitly references sibling tools as individual pipelines and frames the tool as the all-in-one repository-level version, so it is clearly distinguishable from them.

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 explains this is a combined alternative to the individually exposed pipelines and warns that it is the most expensive tool, stating 'don't call it in a loop across many repos.' This gives an agent a clear cost-based usage boundary and names the operations it replaces.

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 have clearly distinct scopes, such as flat vs. transitive vulnerability checks and per-package vs. GitHub-repo audits. The main ambiguity is that several tools all ultimately report OSV/NVD findings or perform install-script risk checks, though the descriptions do draw clear boundaries and include cross-references to steer selection.

Naming Consistency5/5

Every tool follows a consistent lowercase snake_case verb_noun pattern, e.g. analyze_install_script, check_maintainer_changes, prioritize_remediation. The naming is predictable and makes the action and target of each tool immediately clear.

Tool Count3/5

At 22 tools, the surface is at the heavy end of the rubric and pushes beyond the typical 3-15 well-scoped range. The tools are individually purposeful and broad in coverage, but the count is high enough that an agent faces a large decision space and several workflows that overlap or compose in complex ways.

Completeness5/5

The set covers the full npm supply-chain assessment lifecycle: discovery, metadata lookup, vulnerability scanning, transitive dependency analysis, license checks, install-script analysis, maintainer and provenance checks, SBOM generation, dependency diffs, upgrade simulation, remediation prioritization, and alternative suggestion. There are no obvious dead ends or major missing operations for the stated domain.

Resources

Need Help?