Loading ToolBench
MCP server for CPE (Common Platform Enumeration) parsing, matching, validation, formatting, generation, and version comparison
cpe-skills defines 6 well-named, action-verb-based tools (parse_cpe, format_cpe, match_cpe, validate_cpe, generate_cpe, compare_versions) with descriptions present. However, parameter descriptions are minimal or absent, most parameters lack detailed guidance on expected format, constraints, or constraints. Schemas are visible in test definitions but lack structured output documentation. Error handling is basic (test coverage shows 'missing arg', 'invalid', 'unsupported' errors) but lacks actionable recovery guidance. Tools are single-responsibility and domain-focused (CPE/version handling), which is good composition. No security concerns evident (no secrets in params). Main gaps: parameter descriptions are too terse, output schemas undocumented, error messages lack recovery hints.
Compare two version strings and optionally check if they fall within a version range
Convert CPE between formats (2.2, 2.3, or WFN)
Generate a CPE string from individual components
Check if a target CPE matches criteria CPE with optional version matching
Parse a CPE string and extract its components
Validate whether a CPE string is correctly formatted
Output schemas not documented. Tests infer success structure (contains 'result', 'match', 'valid', 'comparison', 'in_range') but no formal response schema definition visible in source. LLMs cannot plan downstream tool chains without knowing return field names and types.
Parameter descriptions are minimal or absent. 'cpe' param described only as 'CPE string to parse (CPE 2.2 or CPE 2.3 format)', lacks detail on what constitutes valid input, expected format variations, or common errors. 'part' in generate_cpe only says 'Part type: a (application), h (hardware), or o (operating system)', should be an enum constraint, not a description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Error messages lack actionable recovery guidance. Tests show errors like 'missing 'cpe'', 'unrecognized', 'invalid', 'error' but no hints on what the LLM should do next (e.g., 'Use validate_cpe to check format first' or 'Supported formats are CPE 2.2 and 2.3'). Per pattern:recovery-guide, errors should guide the LLM to the next tool or action.
'to' parameter in format_cpe lacks enum constraint. Description says 'Target format: 2.2, 2.3, or wfn' but this should be a JSON Schema enum: ['2.2', '2.3', 'wfn']. Test TestMCP_FormatCPE_UnsupportedTarget confirms 'xml' is rejected, but without an enum, the LLM cannot discover valid options before calling.
match_cpe has complex optional behavior (ignore_version boolean flag) but documentation does not explain the effect. Does ignore_version only affect the version field, or does it change matching semantics entirely? Ambiguous intent.
compare_versions 'min' and 'max' parameters are optional but no description of behavior when they are omitted vs provided. Does omitting them skip range check? Return only comparison result? Current description is unclear.