mcp-supply-chain-check
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_packageA | 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. |
| check_sbomA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.