Loading ToolBench
MCP Server for fetching code from NPM packages
This server provides 4 well-named tools with complete input schemas and reasonable descriptions. All tools follow verb_noun naming (get_*, list_*, search_*). Schemas are properly defined with type information and required fields. However, there are significant gaps: output schemas are NOT documented, error handling lacks recovery guidance, and parameter descriptions are minimal. The server accepts natural identifiers (packageName as string) which is good, but does not document expected output structure, making it harder for LLMs to plan downstream operations. Security and composition are adequate for read-only operations.
Fetch source code from an npm package
Get package metadata and information
List all files in an npm package
Search for npm packages by keyword, name, or description
Output schemas are not documented. LLMs cannot predict what fields will be returned, making it impossible to plan chaining calls or extract specific data. E.g., get_npm_package_code returns {path, content} but LLM must guess. search_npm_packages pagination response structure is undocumented.
Error handling lacks recovery guidance. Code calls https.request() with no explicit error messages or guidance on what LLM should do next if a package is not found, network fails, or tarball extraction fails. Errors should state 'Try search_npm_packages() to find the correct name' or similar.
Parameter descriptions are minimal and lack constraint guidance. 'packageName' description does not explain format (e.g., 'scoped packages use @scope/name format'). 'version' has no guidance on valid formats (semver, 'latest', 'next', etc.). 'size' in search_npm_packages lacks explanation of token cost implications for large result sets.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No pagination support documented. search_npm_packages accepts 'from' and 'size' parameters but response structure (total count, has_more, next_offset) is not documented. LLM cannot iterate through results safely.
get_npm_package_code combines file listing and retrieval. When filePath is omitted, it 'returns all files' but this behavior is not defined. Should split into separate discovery (list_package_files) and retrieval (get_npm_package_code with required filePath) or clarify what 'all files' means (size limit, file count, format).