Loading ToolBench
Model Context Protocol server providing tools to query Trustify vulnerability and software composition analysis APIs
The server provides 12 tools with generally clear naming (verb-noun pattern) and reasonable descriptions. However, there are significant gaps in parameter documentation, output schemas are not explicitly documented, and error handling lacks recovery guidance. Parameter descriptions exist but many are minimal (under 50 chars). No tool annotations (readOnlyHint, idempotentHint) are present despite all tools being read-only operations. The trustify_* tools are well-scoped (single responsibility) and parameter constraints are present for most, but inconsistencies in description depth and complete absence of output schema documentation prevent a higher score.
Get a list of advisories from a trustify instance filtering them by severity and publication date and sorted by publish date
Get the details of a advisory from a trustify instance by advisory URI
Call the info endpoint for a trustify instance
Provide a package url-encoded PURL to get the list of vulnerabilities affecting if from a trustify instance
Get the details of a SBOM from a trustify instance by SBOM URI
Provide the SBOM ID URN UUID to get a list of all the advisories with vulnerabilities related to an SBOM from a trustify instance
Output schemas not documented. Tools return data but LLM must infer structure from execution rather than advance knowledge. This prevents downstream tool-chaining planning and increases context waste as LLMs reason about unpredictable response structures.
No tool annotations despite all tools being read-only. readOnlyHint should be applied to all 12 tools to signal to LLMs that they are safe for speculation and do not modify state. This improves agent reasoning and prevents unnecessary caution in planning.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Get a list of packages contained in an sboms from a trustify instance
Get a list of sboms from a trustify instance
Get a list of vulnerabilities from a trustify instance affecting the array of PURLs provided in input
Get a list of vulnerabilities from a trustify instance filtering them by severity and publication date and sorted by publish date
Get the details of a vulnerability from a trustify instance by CVE ID
URL encode a string
Error handling lacks recovery guidance. When a PURL is malformed or a CVE is not found, the tool response should guide the LLM: 'Invalid PURL format. Expected format: pkg:type/namespace/name@version. See https://github.com/package-url/purl-spec for examples.' Currently no such guidance is visible in schema definitions.
Parameter descriptions for complex query syntax (trustify_advisories_list, trustify_vulnerabilities_list) include EBNF grammars that are dense and difficult for LLMs to parse. These should be accompanied by 3-5 concrete, working examples in the description: 'Examples: title=example, modified>2024-01-01&average_severity=high, title=foo|bar'.
No pagination guidance in list tool descriptions. trustify_sboms_list, trustify_vulnerabilities_list, trustify_advisories_list accept 'limit' but descriptions do not clarify: (a) What is the default limit if omitted? (b) What is the maximum allowed? (c) Is there a cursor/offset for results beyond the first page? (d) Does the response include a total_count or next_cursor? Without this, LLMs cannot plan multi-page queries.
trustify_purl_vulnerabilities parameter description states 'Values must be url-encoded' but does not clarify whether the tool expects the PURL string pre-encoded by the caller or if it accepts a raw PURL and encodes internally. This ambiguity invites double-encoding or raw PURL failures. The url_encode tool exists but its relationship to this parameter is not documented.