mcp-supply-chain-check
Related Servers
Alternatives to mcp-supply-chain-check
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceEnables AI agents to submit npm, PyPI, Go, or Maven packages and manifests to the free OSV.dev database and receive per-package and per-advisory results with CVE mappings, CVSS scores, severities, and the versions that fix each issue. It also supports filtering by minimum severity, de-duplicating alias advisories, and machine-readable error/warning rows for CI gates and upgrade recommendations.3MIT
- AlicenseNot gradedqualityBmaintenanceEnables 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.412 npmMIT

@guardbee/mcp-dependencyofficial
AlicenseNot gradedqualityFmaintenanceEnables 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.785 npmMIT- FlicenseNot gradedqualityDmaintenanceScans Python, Node.js, Java/Spring, and PHP dependency manifests for known vulnerabilities using OSV and GitHub Advisory APIs.-
- AlicenseNot gradedqualityCmaintenanceEnables AI coding agents to scan dependency manifests or package lists against OSV.dev for known vulnerabilities and confirmed-malicious packages, returning severity, CVSS and fixed versions while keeping manifests local. Runs as a hosted or local stdio MCP server with a free daily tier and optional per-call x402 payments.14 npmMIT
- AlicenseAqualityDmaintenanceAutomatically 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.17 npm1MIT
TDQS
Scored across 2 tools
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.
Both tools follow the same verb_noun convention (check_package, check_sbom) in snake_case with the shared verb 'check'. Fully predictable pattern.
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.
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.