Loading ToolBench
MCP Server para interactuar con npm y sus servicios. Un servidor MCP completo que permite a los modelos de lenguaje usar npm de forma segura y estructurada.
This npm MCP server has 11 tools with explicit schemas visible in main.ts. All tools are named with verb_noun patterns (npm_search, npm_install, etc.), which is good. However, there are significant gaps in definition quality: (1) All tool descriptions are in Spanish and very terse (15-40 chars), falling below the 50-200 char LLM-optimized baseline and failing the 20-char minimum rule for several tools. (2) Parameter descriptions are minimal and often just restate the parameter name (e.g., 'Directorio del proyecto' for directory parameter). (3) Output schemas are completely absent, no documentation of what each tool returns, violating the critical pattern:tool requirement. (4) No error handling guidance visible, tools just throw generic errors without recovery paths. (5) No input validation rules documented for parameters (e.g., what makes a valid package name, array sizes, timeout behavior). (6) All 11 tools use executeNpmCommand(), which shells out to npm with 30-second timeout, but this shell-injection risk and timeout behavior are never documented. (7) Destructive operations (npm_uninstall, npm_update, npm_audit_fix, npm_run_script) have no confirmation or dry-run patterns despite the pattern:confirmation-request baseline. (8) No rate limiting, no pagination for list results, no field inclusion/exclusion options.
Auditar vulnerabilidades de seguridad
Arreglar vulnerabilidades automáticamente
Obtener información detallada de un paquete
Inicializar un nuevo proyecto npm
Instalar paquetes usando npm
Listar paquetes instalados
Verificar paquetes desactualizados
All tool descriptions are under 50 characters and in Spanish. LLM optimization baseline is 50-200 chars. Example: 'Buscar paquetes en el registro de npm' (34 chars) is too terse for LLM selection reasoning and does not explain when to use vs npm_info.
No output schemas documented. LLMs cannot plan downstream calls or extract results without knowing what fields each tool returns. npm_search returns raw npm registry JSON (not shown), npm_list likely dumps node_modules tree, but no structured schema is visible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Ejecutar un script definido en package.json
Buscar paquetes en el registro de npm
Desinstalar paquetes usando npm
Actualizar paquetes a sus últimas versiones
Parameter descriptions are minimal. 'Directorio del proyecto (opcional)' does not explain expected format (absolute path? relative? CWD default?). 'Término de búsqueda' for search query does not clarify: Is regex allowed? Case-sensitive? Max length? Fuzzy matching behavior?
Destructive operations (npm_uninstall, npm_update, npm_audit_fix, npm_run_script with side effects) lack confirmation or dry-run patterns. An LLM could irreversibly uninstall all dependencies without safeguard.
No error handling guidance. executeNpmCommand() wraps errors as generic 'Error ejecutando comando npm: {error.message}', offering no recovery path or classification (retryable vs user-fixable vs fatal).
Shell injection risk not documented. npm_install with packages=['lodash; rm -rf /'] would pass unsanitized strings to exec(). No validation, no documentation of escaping, no warning about malicious package names.
No pagination for list results. npm_list and npm_outdated can return thousands of items without limit, limit, or cursor parameters. Large results blow context windows.
Tool language mismatch. English tool names (npm_search, npm_install) paired with Spanish descriptions and param names. Inconsistent localization confuses LLM parsing.