Loading ToolBench
OpenFoodFacts MCP Server provides access to the Open Food Facts dataset via a remote MCP server using DuckDB for fast queries. Supports product searches by brand/name, barcode lookups, and nutrition analysis.
Strong naming and clear schema structure. Three tools with good parameter validation (minLength, min/max constraints on numeric types). Descriptions are present and moderately detailed (80-180 chars). Tool names follow verb_noun pattern (search_*, search_by_*). Schemas show proper JSON Schema with types, descriptions, and constraints. However, descriptions lack dependency hints and are somewhat generic. Output schemas are inferred from response struct types but not explicitly documented in the tool registration. Error handling and recovery guidance are not visible in the provided code. Parameter descriptions are adequate but could be more prescriptive about expected behavior and constraints.
Search for a product by its barcode (UPC/EAN)
Search for branded products by their brand and product name. This tool can only be used if brand and product name are both provided and non-empty.
Search for branded products by their brand and product name returning simplified nutrients. This tool can only be used if brand and product name are both provided and non-empty.
Output schemas not documented in tool definitions. Response types are inferred from Go structs (SearchProductsResponse, SearchBarcodeResponse, SearchProductsSimplifiedResponse) but not explicitly defined in the tool registration. LLMs cannot see what fields to expect without explicit schema documentation.
Descriptions lack dependency hints and recovery guidance. 'Search for a product by its barcode' is clear but doesn't guide when to use barcode vs brand+name search, or what to do if a barcode lookup fails. No guidance on prerequisite steps or fallback strategies.
Tool naming duplicates responsibility. search_products_by_brand_and_name and search_products_by_brand_and_name_simplified differ only in output verbosity, not in the conceptual action. This violates the single-responsibility principle and forces LLM reasoning to distinguish between semantically similar tools.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Result limiting and pagination documented but not visible in code. Tool descriptions mention 'default: 3, max: 10' for limit parameter but no guidance on total count returned, cursor-based pagination, or how to handle truncated results.
No error handling or recovery guidance visible in tool definitions. If a search returns no results, the tool should hint at alternatives (e.g., 'try partial brand name' or 'check for spelling'). LLM-facing error messages must guide next steps.