Loading ToolBench
MCP server para cotizar PCs desde el catálogo en MongoDB
Server has two tools with detailed descriptions and acceptable parameter schemas, but lacks proper output schema documentation, error handling guidance, and relies on implicit response structures. Tool naming follows verb_noun conventions (buscar_, armar_) appropriately for Spanish context. Descriptions are thorough (250+ chars each) and explain usage patterns well, including domain-specific guidance (costo vs precioVenta distinction, compatibility specs). However, the code excerpt is incomplete, full output schemas cannot be verified, and error handling patterns are not evident. The server correctly uses enums for constrained inputs (categoria, almacen) and provides thoughtful parameter descriptions. Composition is solid: two complementary, single-responsibility tools. The 'costo vs precioVenta' distinction is well-documented internally but not enforced in parameter validation visible in source. Parameter naming is clear (precioMax, presupuestoTotal, almacen) with good descriptions. Main gaps: no documented output schemas in code, no visible error recovery guidance, and parameter constraints (e.g., limite min/max, presupuestoTotal valid range) are not enforced.
Arma una configuración de PC completa y COMPATIBLE dentro de un presupuesto total dado, usando componentes de un solo almacén (Cusco por defecto). Respeta las restricciones de compatibilidad: la placa coincide en socket con el procesador, la RAM en generación (DDR4/DDR5) con la placa y nunca es SO-DIMM (laptop), la fuente tiene watts suficientes y, si el build no lleva GPU dedicada, el procesador trae video integrado. Devuelve también un chequeo de compatibilidad. Cambiá 'almacen' solo si el usuario quiere armarla en otra ciudad. El presupuesto se interpreta como PRECIO DE VENTA: es lo que el cliente paga, no lo que se gasta comprando las piezas. La respuesta trae 'totalVenta' (cotizalo), 'totalCosto' y 'ganancia' (internos, nunca se le muestran al cliente).
Busca componentes de PC en el catálogo filtrando por precio máximo, categoría y/o texto. Por defecto busca en el almacén de Cusco. Solo cambiá el parámetro 'almacen' a otra ciudad si el usuario pide más variedad, comparar precios entre ciudades, o alternativas fuera de Cusco. Devuelve una lista acotada de productos reales. Cada producto incluye specs de compatibilidad cuando se pudieron derivar: socket (CPU/placa), memoria DDR4/DDR5 (placa/RAM), formato, watts (fuente), sodimm (RAM de laptop) e igpu (procesador: false = NO trae video integrado, así que ese CPU exige una tarjeta de video o el equipo no da imagen). Usá esos campos para no mezclar piezas incompatibles. Cada resultado trae 'disponible': las unidades en esa sede. Si viene 'esMinimo': true, Deltron solo publica que hay MÁS de esa cantidad, así que es una cota inferior y no un número exacto: decilo así al cliente. Cada producto trae DOS montos: 'costo' (lo que se le paga a Deltron, que NUNCA se le muestra al cliente) y 'precioVenta' (lo que se cotiza). Usa SIEMPRE precioVenta al armar una cotizacion o al hablar de plata con el cliente.
Output schemas not documented in tool definitions. Code shows conPrecioVenta() transformation and textResult() wrapper but MCP tool definitions do not include explicit output schema specification. LLMs cannot plan downstream calls or extract required fields (product IDs, compatibility specs, totals).
Error handling and recovery guidance missing. No visible error messages guiding LLM recovery (e.g., 'if catalog query fails, try a broader search'). textResult() wrapper returns unstructured text, parsing errors or API failures leave agent without actionable guidance.
Numeric parameter constraints not enforced. 'limite' and 'presupuestoTotal' lack min/max bounds; 'precioMax' has no validation. Code does not validate these server-side. Unbounded numeric inputs can cause timeouts (limite=999999) or invalid logic (presupuestoTotal=0).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
No visible pagination or result-limit enforcement in buscar_componentes. Default limit is 15, but no documentation of max limit or pagination cursor for beyond-15 results. Large datasets could be truncated silently without agent awareness.
Response structure assumes unstructured text parsing. Both tools return { content: [{ type: 'text', text }] } wrapping. LLMs must parse natural-language output instead of receiving structured JSON with typed fields (product ID, price, availability, specs). This wastes tokens and invites hallucination.
Product/build IDs not returned in responses. If agent needs to reference a specific product from buscar_componentes in a follow-up call (e.g., to add to quote), no product_id is visible. Breaks tool chaining; agent must re-search or infer IDs from response text.
Mutually exclusive parameters not documented. armar_build accepts incluirGpu and incluirMonitor both true/false, but documentation does not clarify budget interactions (does GPU come from the presupuestoTotal, or is it added?). Undocumented parameter relationships cause LLM misuse.