Loading ToolBench
Solid MCP server with well-documented tools and comprehensive schemas. All 10 tools have descriptions and input schemas with proper types. Naming follows verb_noun conventions (get_, search_, add_, upload_, select_, call_). Parameter descriptions are detailed and actionable. However, output schemas are not explicitly documented (responses described only in text, not as formal JSON schemas), and error handling lacks structured recovery guidance. Tool composition is strong, each tool has a single, clear responsibility. The server demonstrates good awareness of API domain complexity and abstracts it well. Descriptions are detailed enough to guide LLM selection, averaging ~150-250 characters per tool.
Add a new product or edit an existing one on Open Food Facts. Requires OFF_USER_ID and OFF_PASSWORD. Supports comprehensive product data including nutrition, packaging, images, and structured fields.
Get autocomplete suggestions for Open Food Facts taxonomy entries (brands, categories, labels, etc.).
Make a direct call to any Open Food Facts API endpoint. Use get_api_docs to see available endpoints. Auth credentials are included automatically for write operations if configured. Two body modes for writes: - params: form-encoded (for /cgi/*.pl and /api/v2/* legacy endpoints) - json_body: raw JSON (for /api/v3/* endpoints — required for structured fields like packagings) Example v3 packagings write: method: PATCH endpoint: /api/v3/product/0123456789012 json_body: {"fields":"packagings","product":{"packagings":[{"number_of_units":1,"shape":{"id":"en:bag"},"material":{"id":"en:plastic"},"recycling":{"id":"en:recycle"}}]}} WARNING: Do NOT use old-style prepared nutrition params like nutriment_fat_prepared — they have a known server bug that stores data incorrectly. Use new-style params instead: nutrition_input_sets_prepared_100g_nutrients_fat_value_string=0.5
Get Open Food Facts API documentation. Useful for understanding available endpoints before using call_api.
Output schemas not formally documented. No tool defines a JSON Schema for the response structure. Descriptions reference response format in prose, but LLMs benefit from structured output specifications to plan follow-up calls and extract fields reliably.
Error handling lacks structured recovery guidance. Tools return errors (implied via OFF API) but descriptions do not explain error categories, what to do on failure, or when to retry. E.g., 'product not found' in get_product is explained contextually, but broader error cases (network timeout, auth failure, invalid barcode format) have no guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Get product information from Open Food Facts by barcode. Reads the primary database directly (no sync lag), so this is always current even when search_products returns stale results. Prefer this over search whenever you have a barcode. If this returns "product not found", the product genuinely isn't in the database — you can add it with add_or_edit_product.
Get the OFF upload skill document. This describes the recommended process for bulk uploading food packaging photos to Open Food Facts.
Search Open Food Facts using the Search-a-licious Elasticsearch backend. Powered by Lucene query syntax with full boolean logic and negation support. Use this instead of search_products_standard when you need: - Negation queries: find gluten-free cereals with allergens_tags_without="en:gluten" - Filter-only browsing: categories_tags without any text query (standard API times out on this) - Combined text + filter with relevance scoring: text matches are ranked by relevance within filter results - Boolean logic in raw Lucene: brands:"kellogg*" OR brands:"nestle" Trade-offs vs search_products_standard: - Counts are approximate (capped at 10,000 for large result sets) - Brand tag matching may be narrower (less normalization than standard) - Data has a short sync delay (hours) from the primary database - popularity sort uses scan counts rather than the standard popularity algorithm Response format matches search_products_standard: { count, page, page_size, page_count, products: [...] }
Search Open Food Facts with structured filters. Best for simple keyword queries and brand/category filtering. Returns exact result counts and well-populated products. If you have a barcode, use get_product instead. How search works: strict AND against a keyword index built from product_name, generic_name, brands, categories, origins, labels. One unmatched query word → zero results. Tips: - Prefer 2-3 distinctive words over the full product name - Put brand names in brands_tags, not the query text - Brand normalization is generous: "sainsburys", "sainsbury's", "sainsbury-s" all match - For fresh produce, use brands_tags + categories_tags rather than text search - sort_by=popularity works well here (not supported in search_products_lucene) If you get zero results, try dropping words or using search_products_lucene which has more flexible text matching.
Select, crop, and rotate a previously uploaded product image on Open Food Facts. Requires OFF_USER_ID and OFF_PASSWORD.
Upload a product image to Open Food Facts. Requires OFF_USER_ID and OFF_PASSWORD. Prefer more photos over fewer. Panels with text (ingredients, nutrition, certifications, recycling instructions) are highest value as OFF can OCR them. Plain sides with just a colour or logo are lowest value but still worth uploading if you have them. Use the most appropriate imagefield (front, ingredients, nutrition, packaging). Use "other" for additional photos — this uploads without selecting the image as a display image, which is useful when a good display image already exists or for supplementary angles. The OFF server auto-selects images for front/nutrition/ingredients/packaging on upload unless one is already selected. If you get "status not ok" but a positive imgid, the image uploaded successfully but was not selected (e.g. a display image already exists). For images on disk, base64-encode them first (e.g. via shell: `base64 -i photo.jpg`).
Discovery/guidance tools (get_api_docs, get_skill) have minimal descriptions. 'Get Open Food Facts API documentation' lacks context on when to call, what structure is returned, or how it fits into the workflow. LLMs need explicit guidance to avoid skipping discovery steps or calling them unnecessarily.
call_api is a generic escape hatch that undermines schema rigor. While useful for advanced flexibility, it increases LLM confusion about when to use domain-specific tools (add_or_edit_product, upload_image) vs the generic endpoint. No guidance on precedence or when call_api should be avoided.
add_or_edit_product has 20+ parameters without documented required vs optional distinction. LLMs cannot determine which fields are mandatory (barcode is mentioned but others unclear) and which combinations are valid. No guidance on what makes a 'minimal valid product' vs a 'complete product'.
select_image lacks workflow context. Description does not explain when/why to call it relative to upload_image, or whether it can be called standalone. No guidance on coordinate system (are crop coordinates image-relative in pixels? percentage? origin at top-left or center?).