Loading ToolBench
MCP server for inspecting and proxying packages with CVE vulnerability checking, typosquatting risk assessment, and quarantine policy enforcement
This MCP server has severe definition quality issues. Only one tool is defined ('execute_skill_action'), and while it has a description and basic input parameters, the implementation is critically incomplete. The source code shows only a mock/stub implementation with no actual MCP protocol handling, mcp_server.py simply prints a JSON status message and exits rather than implementing the MCP server protocol. The tool schema exists but is minimal. The description is present but generic. Most critically, there is no actual tool registration mechanism visible in the code, no input validation, no error handling, and the 'implementation' in client.py is a fake dictionary return that doesn't interact with any real CVE database or package ecosystem. This is a non-functional skeleton.
Execute a skill action for package inspection and proxying with CVE vulnerability checking
Tool name violates verb_noun pattern, 'execute_skill_action' uses a generic verb 'execute' rather than a specific action verb like 'inspect_package' or 'check_cve_vulnerabilities'. The name does not clearly convey what the tool does.
No actual MCP server implementation, mcp_server.py contains only a print statement and does not implement the MCP protocol loop, message handling, or tool invocation. The code is a non-functional skeleton.
Tool description is generic and does not explain WHEN to use this tool or what CVE vulnerabilities means in context. 'Execute a skill action for package inspection and proxying with CVE vulnerability checking' lacks specificity about domain, expected use cases, and what downstream actions to take.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
Input parameter 'package_ecosystem' has a default value of 'NPM' but the parameter is marked as required in the schema. The description mentions 'e.g., NPM, PYPI' as examples rather than enums, LLMs will guess and pass invalid values like 'node' or 'python'. This violates the constrained-input pattern.
No output schema documented. The tool description does not specify what fields the response contains, forcing LLMs to guess. The fake client.py shows a response with 'inspection_id', 'cve_vulnerabilities_found', 'quarantine_policy_verdict', etc., but this is not formally declared as the output schema.
No error handling or recovery guidance. The tool has no documented error cases, error messages, or guidance on what to do if a package is not found, if the CVE database is unavailable, or if the ecosystem is invalid. This violates the recovery-guide pattern.
Parameter descriptions are too brief (10-20 chars) and lack context. 'Package name to inspect' and 'Package version to inspect' do not explain format, constraints (e.g. SemVer), or what happens if the version does not exist.
Tool does not declare permissions or scopes. There is no indication what security boundaries this tool operates within, whether it requires authentication, or what resources it can access.
No input validation visible in code. The tool accepts string parameters with no length limits, format validation, or enum enforcement. An LLM could pass a 10MB package_name string or an invalid ecosystem, and the tool would silently fail or misbehave.