Loading ToolBench
Auto-enrich product catalogs with missing attributes, inferred tags, and completeness scoring
This MCP server has a single tool 'enrich' with significant definition quality gaps. The tool name lacks a clear action verb (should be 'enrich_catalog'), description is present but generic (~120 chars, under the LLM-optimization target of 50-200 chars with specific detail), parameter descriptions exist but lack constraints and format guidance, and critically, there is NO documented output schema despite returning a complex dict with 'enriched_products', 'catalog_health', and 'issues' structures. The implementation is a plain Python class (CatalogEnrichmentClient) with no MCP protocol wrapping visible, suggesting this is either incomplete or a raw SDK, not an actual MCP server. No error handling guidance, no permission gates, no idempotency guarantees documented. The code defines parameter types via Python type hints (list[dict], Optional[list[str]]) but these are not formally exposed as JSON Schema in an MCP tool definition. Combined with missing output schema documentation and absent error handling patterns, the score reflects a prototype-stage implementation.
Enrich a product catalog. Detects missing fields, infers categories and tags, generates descriptions, and scores completeness.
Tool name 'enrich' lacks action verb prefix, should be 'enrich_catalog' or 'enrich_products' to clarify intent. LLMs infer action from verb; 'enrich' alone is ambiguous (enrich what? catalog? a product?).
No documented output schema. Tool returns dict with 'enriched_products' (list of modified product dicts), 'catalog_health' (dict with scores), and 'issues' (list of problem records), but LLMs cannot infer structure without formal schema documentation. This violates the requirement that all tools document their return types.
Parameter 'required_fields' description lacks format/constraint guidance. Should state: 'Optional list of field names to require in each product record (default: ["name", "description", "price", "category", "tags", "images"]). Each field used to calculate completeness score.' Current description is bare.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | 2026-07-28+ | v2 |
Parameter 'products' description is generic ('List of product dicts') and does not specify expected fields, format, or constraints. Should document: 'List of product dicts, each with fields like name, description, price, category, tags, images (optional), id (recommended for tracking). Missing or malformed fields trigger enrichment and scoring.'
No error handling guidance. Tool does not document failure modes (e.g., what if a product has no name? what if price cannot be parsed?). Code shows silent fallbacks (except ValueError for price), but LLMs are not told what to expect or how to interpret partial results.
Tool lacks idempotency and confirmation semantics. Calling enrich() twice on the same catalog may produce different inferred categories/descriptions due to keyword-matching logic; no determinism guarantee. No dry-run mode documented. LLMs cannot safely retry without risk of re-enriching already-enriched data.
No explicit tool registration as MCP Tool object visible in source. Tool definition is inferred from Python class method signature, not registered via MCP protocol (no Tool struct with name, description, inputSchema).
Response field naming not optimized for downstream tool chaining. Returns '_completeness_score', '_changes_made', '_missing_fields' (prefixed with underscore). If an LLM needs to reference these in a follow-up call, it must know to use the underscore prefix. Standard naming (e.g., completeness_score, changes_made) would be clearer.