Skip to main content
Glama
domdomegg

openfoodfacts-mcp

Add or edit product

add_or_edit_product

Add a new food product or update an existing one on Open Food Facts. Provide barcode, name, brands, categories, and other details to improve data quality. Helps build a global, open food database for nutrition and sustainability.

Instructions

Add a new product or edit an existing one on Open Food Facts. Requires OFF_USER_ID and OFF_PASSWORD.

The more fields you fill, the more useful the entry. At minimum provide product_name, brands, and categories — these feed the search index, and a sparse entry won't be findable. If you have a photo of the pack, transcribe everything you can read: ingredients, nutrition, origins, traceability stamps, recycling icons, certifications.

Fields that drive derived data:

  • ingredients_text → allergens, additives, NOVA group, fruit/veg %

  • nutrition + categories → Nutri-Score

  • packagings + origins → Eco-Score

  • product_name + brands + categories + labels → search _keywords

Pitfalls learned the hard way:

  • Free-text packaging shapes get fuzzy-matched against the taxonomy. "Pouch" resolves to "en:pouch-flask" (a stand-up spouted pouch). Use taxonomy IDs like "en:bag" or "en:individual-bag" instead.

  • OFF has no generic "pouch" shape in its taxonomy. For vacuum-sealed individual portions use "en:individual-bag"; for plastic film wrap use "en:film".

Recommended workflow for adding a product from photos:

  1. Check if product exists with get_product first to avoid overwriting good data

  2. Upload photos with upload_image. 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) and "other" for the rest.

  3. Call this tool with all fields you can read from the photos. Set both quantity and serving_size.

  4. Set packagings_complete: true only when all packaging components are listed

For products with only prepared nutrition (jelly mixes, powdered drinks, etc.), use nutrition_prepared instead of nutrition. For values printed as "< 0.5g" on the packet, pass the string "< 0.5" — the less-than modifier will be preserved.

Nutrition fields mirror the label columns: nutrition (per 100g as sold), nutrition_per_serving (per serving as sold), nutrition_prepared (per 100g prepared), nutrition_prepared_per_serving (per serving prepared). OFF auto-derives per-serving from per-100g + serving_size, so nutrition_per_serving is only needed when the label shows explicit per-serving values you want to preserve.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
barcodeYesProduct barcode (EAN-13, UPC-A, EAN-8, etc.). Required. If the product doesn't exist yet, it will be created.
product_nameNoProduct name as it should appear in search results. Start from what's printed on the front of pack, but include the product type if it's not in the headline but is integral to the product — e.g. pack says "Fajita Halloumi" but it's a wrap, so use "High Protein Fajita Halloumi Wrap". Feeds search keywords.
generic_nameNoLegal name / product description, often found near the ingredients, e.g. "Carbonated no added sugar pineapple and grapefruit flavoured soft drink with sweeteners". Feeds search keywords.
brandsNoBrand name(s), comma-separated. For supermarket own-brands include both the sub-brand and the retailer, e.g. "The Fishmonger, Aldi" — this makes the product findable by either brand tag. Feeds search keywords.
quantityNoNet quantity as printed, e.g. "400g", "6 x 330ml", "1L". OFF parses this into product_quantity automatically. Always set this — it is separate from serving_size and OFF will warn "quantity undefined" without it.
categoriesNoCategories, comma-separated, most general first, e.g. "Seafood, Fishes, Salmons, Frozen fishes". Feeds search keywords and enables category browsing.
labelsNoCertifications, claims, and dietary marks, comma-separated, e.g. "Sustainable Seafood MSC, Vegan, High protein, No added sugar, Made in Scotland". OFF canonicalises these against its taxonomy.
ingredients_textNoFull ingredients list verbatim from the pack. Mark allergens with underscores, e.g. "Wholegrain _Wheat_ (53%), _Wheat_ Protein, Sugar, _Barley_ Malt Extract". OFF parses this to detect allergens, additives, and compute NOVA group. Percentages matter for Nutri-Score fruit/veg estimation.
allergensNoAllergens, comma-separated, e.g. "en:gluten, en:milk". Usually auto-detected from ingredients_text underscores, so only set this if ingredients are unavailable.
tracesNo"May contain" allergens, comma-separated, e.g. "en:nuts, en:peanuts, en:milk, en:sesame-seeds, en:soybeans".
originsNoWhere the ingredients come from, e.g. "Scotland" or "Northeast Pacific (FAO 67), Northwest Pacific (FAO 61)". Affects Eco-Score.
emb_codesNoTraceability/health marks — the oval stamp with a country code, e.g. "CN 2100/02398 EC" or "UK MD047 EC". Comma-separated if multiple.
manufacturing_placesNoWhere the product was made/packed, e.g. "Grimsby, United Kingdom".
countriesNoCountries where sold, comma-separated, e.g. "United Kingdom, Ireland".
storesNoRetailers where sold, comma-separated, e.g. "Aldi, Iceland".
packagingsNoStructured packaging components. Each item describes one physical part of the packaging (outer box, inner bag, lid, etc.). This populates the packagings array the UI displays and feeds the Eco-Score. Use taxonomy IDs ("en:box") not free text.
packagings_completeNoSet to true to mark that all packaging components have been listed. Only set this when you are confident the packagings array is complete.
packaging_textNoRecycling instructions and/or packaging information as printed on the pack, e.g. "Tray - Plastic - Recycle\nFilm - Plastic - Do Not Recycle". This is the human-readable text, separate from the structured packagings array.
serving_sizeNoServing size as printed, e.g. "30g", "100g (1 fillet)", "330ml (1 can)". OFF uses this to derive per-serving values from per-100g when per-serving values are not provided explicitly.
nutritionNoNutrition facts as sold, per 100g (or per 100ml for beverages). Transcribe per-100g values exactly as printed — don't back-calculate from per-serving. For values printed as "< 0.5g" on the packet, pass the string "< 0.5" — the less-than modifier will be preserved.
nutrition_per_servingNoNutrition facts as sold, per serving. Use this when the label shows a separate per-serving column alongside per-100g. If omitted and serving_size is set, OFF auto-derives per-serving from per-100g values.
nutrition_preparedNoNutrition facts as prepared, per 100g (or per 100ml). For products like jelly mixes, powdered drinks, instant noodles — anything where the packet shows separate "as prepared" nutrition values.
nutrition_prepared_per_servingNoNutrition facts as prepared, per serving. Use this when the label shows a separate per-serving column for prepared values.
commentNoEdit comment explaining what was changed, shown in product edit history. E.g. "Add nutrition data from packaging photo".
languageNoLanguage code for language-dependent fields (product_name, generic_name, ingredients_text). Defaults to "en". Set to "fr" for French products, etc. This determines which language version of these fields is written.en
extra_fieldsNoRaw form fields for anything else. Useful for less common nutriments (nutriment_sodium, nutriment_calcium, nutriment_vitamin-c) or fields not exposed above. Values are strings.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behaviors beyond the readOnlyHint annotation: it requires authentication, triggers derived data (allergens, NOVA, Nutri-Score, Eco-Score), handles fuzzy matching for packaging shapes, and auto-derives per-serving nutrition. No contradiction with annotations (readOnlyHint: false matches write operation).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headers and bullet points, front-loading core purpose and requirements. However, it is lengthy and contains some repetition (e.g., packaging shape warning in pitfalls and schema field). Given the tool's complexity (26 params, nested objects), the length is mostly justified, but slight trimming could improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers prerequisites, workflow with siblings, pitfalls, field-level details, derived data, and special cases (prepared nutrition, '<' values). It lacks explicit mention of the response format (e.g., success/failure, product URL), but with no output schema, this is acceptable. Overall, it provides comprehensive context for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description adds significant value: explains why brands should include sub-brand/retailer, warns about quantity causing warnings, gives examples for nutrition '< 0.5' strings, and details packaging shape taxonomy pitfalls. It enriches understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Add a new product or edit an existing one on Open Food Facts,' clearly specifying the verb (add/edit), resource (product), and platform. This distinguishes it from sibling tools like get_product (read-only) and upload_image (photo upload).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive usage guidance: prerequisites (OFF_USER_ID, OFF_PASSWORD), recommended workflow (step 1: check with get_product, step 2: upload photos with upload_image, step 3: call this tool), and explicit when-to-use vs. when-not-to-use (e.g., only set packagings_complete when all components are listed). It also contrasts with siblings like get_product for checking existence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/domdomegg/openfoodfacts-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server