Loading ToolBench
An MCP server that provides tools for checking the status of your software supply chain within the context of Secure Chain
The server provides 13 tools with complete input schemas and descriptions. All tools follow a consistent naming pattern (get_* verbs) and have proper type-constrained parameters with enums for package types. However, descriptions are functional but generic, lacking the strategic context that would help LLMs decide between similar tools. Output schemas are not documented in the source code, responses are JSON-encoded but the structure is not formally specified. Error handling is present but minimal; exceptions are caught and returned as text without guidance on recovery steps. The tool set is well-organized around supply chain analysis but lacks composition guidance and chaining support.
Use this to get the information of a CWE by the ID. Input: cwe_id: The ID of the CWE to look for.
Use this to get the information of CWEs related to a vulnerability ID. Input: vulnerability_id: The ID of the vulnerability to look for associated cwes.
Use this to get the information of an exploit by the ID. Input: exploit_id: The ID of the exploit to look for.
Use this to get the information of exploits related to a vulnerability ID. Input: vulnerability_id: The ID of the vulnerability to look for associated exploits.
Use this to check the direct and transitive software supply chain of a package in the dependency graph of the overall software supply chain. Input: node_type: Type of node (PyPIPackage, NPMPackage, MavenPackage, CargoPackage, RubyGemsPackage, NuGetPackage). package_name: Name of the package.
Use this to check if a package exists and get its status in the dependency graph. Input: node_type: Type of node (PyPIPackage, NPMPackage, MavenPackage, CargoPackage, RubyGemsPackage, NuGetPackage). package_name: Name of the package.
Output schemas not documented. The code returns JSON-encoded TextContent, but the structure of the returned objects (fields, types, hierarchy) is not formally specified. LLMs cannot plan downstream tool calls or field extraction without knowing response shape.
Descriptions lack strategic context. Descriptions like 'Use this to check if a package exists and get its status in the dependency graph' are functional but do not explain WHEN to use this tool vs. get_package_ssc, what 'status' means, or what result structure to expect. Missing: 'Returns package metadata including version count, vulnerability count, and SSC depth.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 68 | - | v1 |
Use this to get the Threat Intelligence eXchanges (TIXs) for a given repository owner and name. Input: owner: The owner of the repository. name: The name of the repository. sbom_name: The name of the SBOM file.
Use this to check the direct and transitive software supply chain of a version in the dependency graph of the overall software supply chain. Input: node_type: Type of node (PyPIPackage, NPMPackage, MavenPackage, CargoPackage, RubyGemsPackage, NuGetPackage). package_name: Name of the package. version_name: Name of the version.
Use this to get the status of a specific version of a package in the dependency graph. Input: node_type: Type of node (PyPIPackage, NPMPackage, MavenPackage, CargoPackage, RubyGemsPackage, NuGetPackage). package_name: Name of the package. version_name: Name of the version.
Use this to get the Vulnerability Exploitability eXchanges (VEXs) for a given repository owner and name. Input: owner: The owner of the repository. name: The name of the repository. sbom_name: The name of the SBOM file.
Use this to get the information of a vulnerabilities related to a CWE by the CWE-ID. Input: cwe_id: The ID of the CWE to look for.
Use this to get the information of a vulnerabilities related to a exploit by the exploit ID. Input: exploit_id: The ID of the exploit to look for.
Use this to get the information of a vulnerability by the ID. Input: vulnerability_id: The ID of the vulnerability to look for.
Error handling is generic and non-actionable. Examples: 'Error: {e!s}' and 'Package {package_name} of type {node_type} not Found.' do not guide recovery. Missing: 'Package not found. Call get_package_status with a different package_name, or list available packages.' No distinction between retryable vs. fatal errors.
No pagination or result-limiting documented. Tools like get_vulnerabilities_by_cwe could return hundreds of records with no limit or next_cursor, blowing context windows. No cap on result size is stated in descriptions.
Parameter descriptions lack format/constraint details. node_type accepts an enum, but description says only 'Type of node', does not list valid values or explain impact of choice. package_name has no length constraints, regex pattern, or hints on case sensitivity.
No composition guidance. Tools are read-only and standalone, but the server does not document which tools typically chain together (e.g., 'After get_vulnerability, call get_cwes_by_vulnerability_id and get_exploits_by_vulnerability_id to build a full threat picture'). Missing: dependency hints in descriptions.