Loading ToolBench
MCP server for npm package management — publish, version, search, audit, and more from your AI assistant
npm-mcp provides 12 tools with complete Zod schemas and descriptions for all parameters. However, there are systemic quality gaps: (1) Most tool names lack clear action verbs (e.g., 'publish', 'version', 'view' are acceptable, but 'owner' and 'dist-tag' are ambiguous commands without imperative framing). (2) Tool descriptions are adequate (94 - 187 chars) but lack LLM-optimized guidance on WHEN to use each tool or recovery paths on failure. (3) Output schemas are not formally documented, responses are inferred as text content, not structured objects. (4) No error messages guide the LLM on recovery ('Try search_users()' patterns absent). (5) Destructive operations (unpublish, deprecate, version) lack confirmation/dry-run safeguards mentioned in descriptions. Per-tool analysis: All 12 tools have valid Zod input schemas with type and description, placing them at 70 - 75 individually; however, missing output schema documentation and weak error guidance lower the average.
Run a security audit on the package
Deprecate a version of a package
Manage distribution tags
Initialize a new package.json
Manage package owners
Create a tarball from a package (preview what would be published)
Publish a package to the npm registry
Ambiguous tool names: 'owner' and 'dist-tag' do not start with action verbs and do not clearly convey what they do. LLMs may confuse 'owner' (manage package owners) with 'whoami' (check authenticated user). 'dist-tag' is a CLI subcommand, not an action verb.
Output schemas are not formally documented. All tools return { content: [{ type: 'text', text: string }] }, but the structure and content format are inferred, not explicitly declared in tool definitions. LLMs cannot plan downstream operations or validate parsing.
Error handling lacks recovery guidance. All tools catch errors and return { content: [{ type: 'text', text: `Error: ${e.stderr || e.message}` }], isError: true }. This gives LLMs raw npm stderr (often multi-line, verbose) with no guidance on what to try next. E.g., 'Package not found' could be handled as 'Try search() first to confirm the package name.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Search npm registry for packages
Remove a package version from the registry
Bump the package version
View package information from the registry
Check which npm user is currently authenticated. If not logged in, set NPM_TOKEN env var in MCP config.
Destructive operations (unpublish, deprecate, version) lack confirmation or dry-run safeguards despite npm CLI supporting --dry-run for publish. No pattern.confirmation-request or explicit undo mechanism. 'version' and 'unpublish' can permanently alter package state.
Tool descriptions do not explain WHEN to use each tool or dependencies between tools. E.g., 'init' should mention it creates a package.json for new projects; 'version' should note it requires an existing package.json; 'audit' should explain it runs npm audit and when to call it vs other tools.
Missing pagination support for list-like operations. 'search' accepts a limit but no offset/page parameter. 'view' may return large JSON (e.g., all versions of a popular package). No guidance on result truncation or how to fetch more data.
NPM_TOKEN is injected via environment variable (correct practice), but there is no guidance in tool descriptions on how to authenticate. 'whoami' description mentions 'set NPM_TOKEN env var in MCP config', this is implementation detail leakage. The MCP server should abstract authentication; users should not see environment variable names in descriptions.
Parameter descriptions lack constraints for open-ended fields. 'path' in publish, version, init, pack, audit accepts any string with description 'Absolute path to the package directory', no validation that the path exists, is a directory, or contains package.json. LLMs may pass invalid paths.
Tool 'deprecate' message parameter description says 'empty string to undeprecate' but does not explain what constitutes a valid message. Length limits, character restrictions, and markdown vs plaintext are not documented.