How do I use mcp-supply-chain-check?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-supply-chain-check Can you check lodash 4.17.15 for known vulnerabilities?" 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.

mcp-supply-chain-check

by MuellerMH

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

mcp-supply-chain-check

Ein MCP-Server, der Coding-Agenten (z. B. Claude Code) einen Supply-Chain-/SBOM-Sicherheitscheck für Projektabhängigkeiten als Tool bereitstellt — gegen die öffentliche, kostenlose OSV.dev-Advisory-Datenbank, ohne API-Key.

Zwei Tools:

check_package — prüft ein einzelnes Paket (Ecosystem, Name, optional Version) gegen OSV.dev und gibt gefundene Advisories mit einer Kurz-Einschätzung zurück.
check_sbom — liest eine lokale CycloneDX- oder SPDX-JSON-SBOM-Datei, prüft alle enthaltenen Komponenten in einer Batch-Abfrage gegen OSV.dev und gibt eine nach Advisory-Anzahl sortierte Liste betroffener Komponenten zurück.

Installation

npm install

Voraussetzung: Node.js >= 18. Benötigt Internetzugriff auf api.osv.dev, sonst keine Abhängigkeit zu Drittdiensten oder internen Systemen.

In Claude Code registrieren

claude mcp add supply-chain-check -- node /pfad/zu/mcp-supply-chain-check/src/index.js

Alternativ nach npm install -g . über den Bin-Eintrag:

claude mcp add supply-chain-check -- mcp-supply-chain-check

Der Server spricht ausschließlich stdio (kein HTTP-Port, keine offene Netzwerk-Schnittstelle außer dem ausgehenden Aufruf an api.osv.dev).

Related MCP server: dep-guard-mcp

Beispiel-Aufrufe

`check_package`

{ "ecosystem": "npm", "name": "lodash", "version": "4.17.15" }

liefert u. a.:

npm/lodash@4.17.15: 1 Advisory(s) gefunden — Einschätzung: unauffällig
- GHSA-29mw-wpgm-hmr9 [MODERATE]: Regular Expression Denial of Service (ReDoS) in lodash (aliases: CVE-2020-28500)

ecosystem folgt den OSV.dev-Ecosystem-Namen (npm, PyPI, Go, crates.io, Maven, RubyGems, NuGet, Packagist, …). version ist optional; ohne Angabe werden alle bekannten Advisories des Pakets über alle Versionen hinweg gemeldet.

`check_sbom`

{ "path": "/pfad/zu/sbom.cdx.json" }

liefert eine nach Advisory-Anzahl sortierte Liste betroffener Komponenten, plus Hinweis auf übersprungene Komponenten (kein erkennbares Ecosystem/purl) und auf Kürzung, wenn die SBOM mehr als 200 Komponenten enthält. Unterstützt werden CycloneDX (components[].name/version/purl) und SPDX (packages[].name/versionInfo, Ecosystem-Erkennung über externalRefs[].referenceType: "purl").

Einschätzung

Die Kurz-Einschätzung ist kritisch, wenn mindestens eine Advisory als HIGH/CRITICAL eingestuft ist oder mehr als eine Advisory gefunden wurde, sonst unauffällig. Das ist eine grobe Heuristik für einen schnellen Überblick, kein CVSS-Scoring — die vollständigen Advisory-Daten (inkl. aller Referenzen) stehen über die zurückgegebenen IDs auf osv.dev zur Verfügung.

Transparenz: Rechte und Datenfluss

Der Server läuft als lokaler stdio-Prozess mit genau den Dateisystemrechten des aufrufenden Agenten/Clients (z. B. Claude Code) — er kann nichts lesen, was dieser Prozess nicht auch lesen könnte, und erweitert dessen Zugriff nicht.

Bei check_sbom werden aus der lokal gelesenen SBOM-Datei Paketname, Version und Ecosystem je Komponente extrahiert und zur Abfrage an die externe OSV.dev-API (api.osv.dev) gesendet — nicht der Dateiinhalt oder der Dateipfad selbst, aber die darin enthaltenen Komponentenangaben verlassen damit die lokale Maschine. Wer das nicht möchte (z. B. bei SBOMs mit sensiblen internen Paketnamen), sollte den Server nicht gegen solche Dateien laufen lassen.

Datenquelle

Alle Daten stammen von OSV.dev, dem offenen, kostenlosen Schwachstellen-Datenbank-Aggregator von Google (Daten lizenziert unter CC-BY 4.0). Dieses Projekt steht in keiner Verbindung zu Google oder OSV.dev und ist kein offizielles Produkt davon.

Tests

npm test

Läuft mit Node's eingebautem node:test, keine echten Netzwerkaufrufe (OSV-Antworten werden in den Tests gemockt).

Lizenz

MIT, siehe LICENSE.

Available Tools

2 tools

check_packageSupply-Chain-Check für ein PaketA

Prüft ein einzelnes Paket (Ecosystem, Name, optional Version) gegen die öffentliche OSV.dev-Advisory-Datenbank und gibt gefundene Advisories mit einer Kurz-Einschätzung zurück.

Name	Required	Description
`name`	Yes	Paketname
`version`	No	Paketversion (optional); ohne Angabe werden alle bekannten Advisories des Pakets gemeldet
`ecosystem`	Yes	OSV.dev-Ecosystem-Name, z. B. "npm", "PyPI", "Go", "crates.io"

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the external data source (public OSV.dev) and that results include a short assessment, which implies a read-only lookup, but it does not state read-only semantics, network/auth requirements, or rate limits explicitly.

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?

A single well-formed sentence with the resource and data source front-loaded and no wasted wording. It is appropriately sized for a simple lookup tool.

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

Completeness4/5

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

For a simple read-only lookup with no output schema, the description covers what is queried, against what, and roughly what is returned. Only the explicit read-only/network behavior is left implicit.

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?

Schema coverage is 100%, so the schema already documents all three parameters. The description restates ecosystem/name/optional version and the no-version behavior, which is already in the schema, adding no new syntax or format detail beyond it.

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

Purpose4/5

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

The description names a specific verb ("Prüft") and resource ("einzelnes Paket") and identifies the data source (OSV.dev advisory database). The word "einzelnes" implicitly contrasts with the sibling check_sbom, though it never names it explicitly.

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

Usage Guidelines3/5

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

Usage is implied by "einzelnes Paket" (single package vs. an SBOM), but there is no explicit statement of when to prefer this over check_sbom or any prerequisites. The agent must infer the routing.

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

check_sbomSupply-Chain-Check für eine SBOM-DateiA

Liest eine lokale CycloneDX- oder SPDX-JSON-SBOM-Datei, prüft alle enthaltenen Komponenten (max. 200, Hinweis bei Kürzung) in einer Batch-Abfrage gegen OSV.dev und gibt eine nach Advisory-Anzahl sortierte Liste betroffener Komponenten zurück.

Name	Required	Description	Default
`path`	Yes	Pfad zu einer lokalen CycloneDX- oder SPDX-JSON-Datei

TDQS

A3.8/5.0

Behavior4/5

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

Ohne Annotationen trägt die Beschreibung die volle Last und liefert wertvolle Verhaltensdetails: Batch-Abfrage, Komponentenlimit von 200 mit Hinweis bei Kürzung und Sortierung nach Advisory-Anzahl. Fehlerfälle (ungültige Datei, Netzwerkfehler) und benötigte Berechtigungen bleiben unerwähnt.

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

Conciseness5/5

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

Ein einziger, dicht gepackter Satz, der Zweck, Input, Limit und Rückgabe in sinnvoller Reihenfolge voranstellt. Kein Füllmaterial.

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

Completeness4/5

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

Für ein Tool mit einem Parameter und ohne Output-Schema beschreibt die Definition das Rückgabeformat hinreichend (sortierte Liste betroffener Komponenten). Lediglich das Verhalten bei Fehlern oder leerem Ergebnis fehlt.

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?

Schema-Deckung liegt bei 100 %, der einzige Parameter path ist dort bereits dokumentiert. Die Beschreibung wiederholt nur das Dateiformat, ohne zusätzliche Syntax- oder Formatdetails zu liefern – Baseline 3.

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

Purpose4/5

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

Klarer Verb+Objekt-Kern: liest eine lokale CycloneDX/SPDX-JSON-SBOM, prüft Komponenten gegen OSV.dev und liefert betroffene Komponenten. Die Abgrenzung zum Sibling check_package bleibt implizit (Datei-Ebene vs. Einzelpaket), wird aber durch den Namen gestützt.

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

Usage Guidelines3/5

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

Der Einsatzfall (Prüfung einer ganzen SBOM-Datei) ist impliziert erkennbar, es fehlen jedoch explizite Wann/Wann-nicht-Hinweise und ein Verweis auf check_package als Alternative für Einzelpakete.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Nov 5, 2026
- First observedcheck_package
- First observedcheck_sbom

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A3.8/5.0

Scored 2026-11-05 09:35 across 2 tools

Disambiguation5/5

check_package targets one ecosystem/name/version tuple, while check_sbom targets a local SBOM file and batch-resolves its components. The input types and scopes are explicitly disjoint, leaving no realistic way to confuse them.

Naming Consistency5/5

Both tools follow the same verb_noun convention (check_package, check_sbom) in snake_case with the shared verb 'check'. Fully predictable pattern.

Tool Count3/5

Two tools cover the two natural granularities (single component vs. whole SBOM), so each earns its place, but the surface is thin for a 'supply-chain-check' server. There is no room for related operations like manifest/lockfile scanning or advisory detail lookup, making the set feel under-scoped.

Completeness4/5

Core lifecycle for vulnerability checking is covered: ad-hoc single-package lookup plus batch SBOM verification with truncation handling. Minor gaps remain (no lockfile/manifest input such as package.json or requirements.txt, and no way to fetch deeper advisory detail or remediation info), but agents can work around these by looping check_package.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Related MCP Connectors

OSV Dependency Vulnerability Check
io.github.fairquery
Check npm, PyPI, Go and Maven packages or lockfiles against OSV.dev: CVEs, CVSS, fixed versions.
Security Penetration Testing Developer Tools
1
https://mcp.apify.com/?tools=fetch-actor-details,fairquery/osv-dependency-vulnerability-check
Security Intel MCP A
com.datakoot
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Penetration Testing Security
51
https://security.datakoot.com/mcp
Security Intel MCP A
io.github.selflabbs
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Security Penetration Testing
2
https://security.selflabbs.com/mcp
SBOMApp - SBOM Generator & Vulnerability Scanner
io.github.mcpsbom
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Developer Tools Security Testing & QA Tools
2
https://mcp.sbomapp.com/mcp

Related MCP Servers

GuardianMCP
Developer Tools Security Testing & QA Tools
Kalvisan
A
license
A
quality
D
maintenance
Automatically scans project dependencies (npm, Composer) for security vulnerabilities using the OSV.dev database, providing real-time alerts and detailed remediation guidance directly in your IDE.
Updated a year ago (2025-11-26 11:18 UTC)
1
7 npm
1
MIT
dep-guard-mcp
Security CI/CD & DevOps Code Analysis
mdjahidanwar
F
license
Not graded
quality
D
maintenance
Scans Python, Node.js, Java/Spring, and PHP dependency manifests for known vulnerabilities using OSV and GitHub Advisory APIs.
Updated 7 months ago (2026-03-29 19:29 UTC)
-
@guardbee/mcp-dependencyofficial
CI/CD & DevOps Penetration Testing
GuardBee
A
license
Not graded
quality
F
maintenance
Enables auditing npm, pip, and other package dependencies for known CVEs via the OSV database, with tools to scan manifests, query individual packages, and integrate into CI/CD workflows.
Updated 2 months ago (2026-09-09 14:25 UTC)
785 npm
MIT
mcp-osv
Security Penetration Testing Developer Tools
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables AI agents to look up known open-source vulnerabilities in the OSV.dev database, covering individual packages and versions, specific git commits, single vulnerability IDs, and batch SBOM-style dependency scans. Queries are keyless and return compact summaries or full vulnerability details with affected ranges and references.
Updated 2 days ago (2026-11-04 01:55 UTC)
412 npm
MIT

mcp-supply-chain-check

Installation

In Claude Code registrieren

Beispiel-Aufrufe

check_package

check_sbom

Einschätzung

Transparenz: Rechte und Datenfluss

Datenquelle

Tests

Lizenz

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

GuardianMCP

dep-guard-mcp

@guardbee/mcp-dependencyofficial

mcp-osv

`check_package`

`check_sbom`