Loading ToolBench
A basic MCP server implementation that provides product catalog tools integrated with an Express API backend and OpenRouter LLM calls
This server has critical definition quality issues. Both tools have minimal descriptions (under 50 chars), lack comprehensive error guidance, and the overall structure suggests a demo/proof-of-concept rather than production-ready MCP. The tools are registered in mcp.js but are not actually integrated with an MCP server implementation, the code uses OpenRouter API directly with tool definitions formatted for Claude/OpenAI, not for MCP protocol. No proper MCP transport is implemented. Naming is acceptable but descriptions lack context. Parameter validation and error handling are nearly absent.
Devuelve los productos disponibles desde la API
Devuelve un producto específico basado en su ID
Descriptions are too short and lack context. 'Devuelve los productos disponibles desde la API' (42 chars) and 'Devuelve un producto específico basado en su ID' (47 chars) are below the recommended 50-200 char range. They do not explain WHEN to use each tool or what structure is returned.
Parameter 'id' in obtener_producto_por_id lacks format constraints. Description only says 'El ID del producto que se desea obtener' (39 chars). No mention of valid range, whether IDs are 1-based, or what happens if the ID does not exist. Baseline: param descriptions average 72 chars.
No output schema documented. The tools return product objects but LLMs cannot see the structure of the response (fields like 'id', 'name', 'price', 'cantidad'). This forces the LLM to infer structure from examples and risks hallucination.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No pagination support. listar_productos returns a hardcoded 5-item array, but the tool has no limit or page parameters. If the dataset grows, the response will become unmanageably large and blow token budgets.
Error handling is minimal. In mcp.js, errors are logged to console but not returned to the LLM with actionable guidance. When obtener_producto_por_id fails (ID not found), it returns {error: 'Producto no encontrado'}, no context on valid IDs or recovery steps.
This is NOT a valid MCP server implementation. The code in mcp.js uses axios to call OpenRouter's Chat Completions API directly, passing tool definitions in OpenAI format. There is no MCP server (no stdio, HTTP, or SSE transport). The server.js is a standalone Express app serving /products and /products/:id endpoints. The two files are not integrated.