Loading ToolBench
MCP server for checking package versions across multiple package managers
Strong tool naming (all verb-noun format) and comprehensive parameter schemas with enums. Descriptions are well-written (150-250 chars, above baseline 194) and explain WHEN to use each tool. All 6 tools have complete input schemas with proper types and descriptions. However, output schemas are not documented in the code, LLMs cannot see what fields to expect from responses. Error handling is basic (generic validation only). No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. Batch tools (get_latest_versions, check_versions_exist, get_packages_info) are well-designed for composition but lack pagination/limit documentation in descriptions.
Check if a specific version exists. Use for dependency validation, CI/CD checks, or ensuring version compatibility. Returns whether the version exists with package details and timestamp.
Check if specific versions exist for multiple packages. Use for bulk dependency validation, CI/CD pipeline checks, or ensuring multiple package version compatibility. Processes up to 100 packages in parallel with individual error handling.
Get the latest version of a package. Use for dependency updates, version checks, or when you need the most recent stable release. Returns package name, latest version, description, and timestamp.
Get latest versions for multiple packages simultaneously. Use when checking 3+ dependencies - processes up to 100 packages in parallel. Returns individual results for each package with error isolation. Much faster than individual calls for multiple packages.
Get detailed package information including all versions. Use for dependency audits, security reviews, or when you need comprehensive package metadata. Returns versions list, homepage, repository, and full package details.
Output schemas not documented. LLMs cannot see what fields responses contain (e.g., does get_latest_version return 'version' or 'latest_version'? Does it include 'timestamp'?). This forces agents to guess field names and breaks downstream tool chaining.
Batch tools lack pagination/limit documentation. Descriptions claim 'processes up to 100 packages in parallel' but do not explain what happens if >100 are passed, whether results are paginated, or how to handle large result sets. This violates the pattern:paginated-result baseline.
No tool annotations despite all tools being read-only. Adding readOnlyHint=true to all 6 tools would signal to agents that these are safe to call without side effects, enabling better planning and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Get comprehensive package details for multiple packages. Use for dependency audits, security reviews, or bulk package analysis. Processes up to 100 packages in parallel. Returns detailed info for each package with error isolation - failed packages don't break the batch.
Error handling is minimal. The CallToolRequestSchema handler only validates that args is an object and required params exist. No guidance on what to do if a package is not found, registry is unreachable, or version format is invalid. Errors should include recovery hints (e.g., 'Package not found. Try search_packages() with a partial name.').
Batch tool descriptions do not clarify per-item error isolation. The description says 'error isolation' but does not explain: if 3 of 100 packages fail, does the tool return 97 successes + 3 errors, or does it fail entirely? This ambiguity breaks agent error handling.