Loading ToolBench
MCP server for managing MongoDB collections with CRUD operations and product management
This MCP server has severe structural and documentation quality issues. All 6 tools share a critical anti-pattern: bloated parameter lists filled with n8n-specific fields that are marked as 'ignored'. Tool descriptions exist but are minimal and lack clarity about when to use each tool. Schemas are present but include 15+ extraneous parameters per tool that should never exist in a production MCP definition. The core MongoDB operations (list, filter, insert, delete, update, count) are correctly implemented at the MongoDB level, but the tool interface design violates fundamental composition and parameter design principles. No error handling guidance, no output schemas documented, no pagination support for list_content despite potentially returning hundreds of documents.
Cuenta los productos en la colección. Args: filtro: Diccionario opcional con criterios de filtrado Returns: Número de productos que coinciden con el filtro
Elimina un producto de la colección. Args: filtro: Diccionario con los criterios para identificar el producto a eliminar Returns: Mensaje de confirmación
Busca un producto en la colección según el filtro proporcionado. Args: filtro: Diccionario con los criterios de búsqueda (ej: {"idProducto": 1}) Returns: Documento encontrado o mensaje de error si no existe
Inserta un nuevo producto en la colección. Args: producto: Diccionario con los datos del producto a insertar Returns: Mensaje de confirmación con el ID del producto insertado
Herramienta para listar todo el contenido de la colección. Returns: Lista de todos los documentos en la colección (convertidos a JSON serializable)
All tools accept 15+ n8n-specific parameters (update_id, message, toolCallId, type, user, ts, client_msg_id, text, team, blocks, channel, event_ts, channel_type, sessionId, action, chatInput) marked as 'ignored'. This is a fundamental anti-pattern: MCP tools should never expose framework-specific cruft. These parameters bloat the schema, confuse LLMs about what inputs matter, and violate the Single Responsibility Principle.
list_content has no pagination, limit, or offset parameters. The description states it returns 'Lista de todos los documentos' (list of all documents). For a collection that could contain thousands of products, returning unbounded results will blow context windows and fail LLM reasoning. Production tools must support page/offset and limit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Actualiza un producto en la colección. Args: filtro: Diccionario con los criterios para identificar el producto actualizacion: Diccionario con los campos a actualizar (sin $set, se añade automáticamente) Returns: Mensaje de confirmación Ejemplo: filtro = {"idProducto": 1} actualizacion = {"precioUnitarioUSD": 50, "nombre": "Nuevo Nombre"}
No output schemas documented. The tools have return type hints in code (List[Dict[str, Any]], Dict[str, Any], str) but the MCP schema does not declare what fields are returned. LLMs cannot plan downstream calls or extract the right data without knowing: does filter_product return _id, idProducto, nombre, precioUnitarioUSD? Is the response wrapped in a 'data' field?
Error handling is minimal. delete_product returns a string message like 'Producto eliminado: {filtro}' on success or 'No se encontró ningún producto...' on failure. There is no structured error response, no error code, no guidance about whether to retry, and no recovery suggestions. Per the rubric, 'Error responses must tell the LLM what to do next'.
Descriptions are minimal and lack action context. 'Herramienta para listar todo el contenido de la colección' (tool to list all collection content) tells the LLM what the tool does but not WHEN to use it, what it returns structurally, or how it differs from filter_product. Per baselines, descriptions should be 50-200 chars and answer: What? When? Return type? These descriptions are 40-100 chars and skip context.
No confirmation or dry-run for destructive operations. delete_product and update_product modify data irreversibly. Per the rubric, 'Irreversible operations should support a dry-run or confirmation step.' An LLM could accidentally delete all products with a malformed filter. No guards exist.
Parameter relationship documentation missing. update_product requires both 'filtro' (search criteria) and 'actualizacion' (update dict). The description explains the format (e.g. '$set is added automatically') but does not warn what happens if filtro matches 0 documents or multiple documents. Does update_product update all matches or one? Ambiguous relationships cause silent misuse.
Naming clarity issue: filter_product suggests a filtering/search operation, but it returns a single document or error, not a filtered list. A more precise name would be search_product_by_filter or get_product. The name alone does not convey it's a lookup, not a list operation.