Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openfoodfacts-mcp-server What are the allergens in product 3017620422003?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for Open Food Facts — the world's largest open-source food product database with 3M+ products from 200+ countries. No API key required.
Barcode Lookup — Get full product info by EAN barcode
Product Search — Search 3M+ products by name, ingredient, or brand
Nutrition Facts — Detailed nutritional data + Nutri-Score (A–E)
Allergen Check — All 14 EU major allergens + traces
Eco-Score — Environmental impact, CO₂ footprint, packaging info
Find Alternatives — Find healthier or more eco-friendly products
Additives / E-Numbers — List all additives in a product
Labels & Certifications — Organic, Vegan, Fairtrade, Halal, Kosher, Gluten-Free
Related MCP server: agriculture-mcp-server
pip install openfoodfacts-mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"openfoodfacts": {
"command": "openfoodfacts-mcp-server"
}
}
}openfoodfacts-mcp-serverTool | Description |
| Full product info by EAN barcode |
| Search products by name, ingredient, or brand |
| Nutrition data + Nutri-Score explanation |
| All 14 EU allergens + traces |
| Eco-Score + CO₂ + packaging info |
| Better products by Nutri-Score or Eco-Score |
| E-numbers / additives list |
| Organic, Vegan, Fairtrade, Halal, Kosher, etc. |
"What are the allergens in product 3017620422003?"
"Find vegan pasta products with a good Nutri-Score"
"What is the eco-score of this chocolate bar?"
"Find healthier alternatives to this snack"
"List all E-numbers in product 5449000214911"All data comes from Open Food Facts — a free, open-source, collaborative food database. No API key required. Data is available under the Open Database License (ODbL).
MIT © AiAgentKarl
Prueft alle Allergene und Spurenbestandteile eines Produkts. Gibt eine strukturierte Liste der 14 EU-Hauptallergene zurueck.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Produkts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool checks allergens and trace components and returns a structured list, but does not mention permissions, rate limits, or side effects. Since the tool appears read-only, a basic level of transparency is achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the action in the first sentence and the output format in the second. Every word is essential, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and the existence of an output schema (not shown but indicated), the description provides sufficient context. It could be enhanced by mentioning the specific output structure, but the current version is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'barcode' parameter described as 'EAN-Barcode des Produkts'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Prueft alle Allergene und Spurenbestandteile eines Produkts' and specifies the output as a list of the 14 EU main allergens. The verb 'Prueft' and resource 'allergens' are specific, and the tool is distinct from siblings like 'get_nutrition_facts' or 'get_product_additives'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking allergens of a product via barcode but provides no explicit guidance on when to use this tool versus alternatives like 'get_product_additives' or 'lookup_product_by_barcode'. No when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Findet gesundheitlich oder oekologisch bessere Alternativen zu einem Produkt. Sucht in derselben Produktkategorie nach besser bewerteten Optionen.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Referenzprodukts | |
| besser_nutriscore | No | Nur Produkte mit besserem Nutri-Score zurueckgeben | |
| besser_ecoscore | No | Nur Produkte mit besserem Eco-Score zurueckgeben | |
| max_results | No | Maximale Anzahl der Alternativen (1-10) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool searches in the same product category and returns better-rated options, but it does not mention important behavioral traits such as read-only nature, rate limits, or what happens if no alternatives are found. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loaded with the core purpose and followed by a clarifying detail. Every word earns its place, with no wasted or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 100% parameter coverage, the description is fairly complete. It explains the tool's function and the category constraint. It could mention sorting or criteria ordering, but overall it is sufficient for an AI agent to understand the tool's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all parameters. The description adds minimal extra meaning beyond the schema, mostly restating that alternatives are based on health or ecological scores. With high coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it finds healthier or ecologically better alternatives to a product, searching within the same product category for better-rated options. This is a specific verb-resource pairing and distinguishes it from sibling tools like lookup_product_by_barcode or search_food, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding alternatives based on health or ecological criteria, but it does not explicitly state when to use this tool versus siblings like get_nutrition_facts or get_eco_score. No when-not conditions or alternative tools are mentioned, so guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ruft den Eco-Score und Umweltinformationen eines Produkts ab. Gibt CO2-Fussabdruck, Verpackung, Herkunft und Umweltbewertung zurueck.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Produkts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output fields but does not mention any side effects, authentication needs, rate limits, or whether the operation is read-only. For a simple query tool, this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no annotations, and an output schema (exists but not shown), the description provides sufficient context about what the tool returns. However, it could mention that it is a read operation or reference the output schema. Still, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'barcode' parameter. The description does not add any additional meaning or context beyond what the schema already provides (EAN-Barcode des Produkts).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: retrieving Eco-Score and environmental information of a product, listing specific output fields (CO2 footprint, packaging, origin, environmental rating). This clearly distinguishes it from sibling tools like get_nutrition_facts or get_product_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ruft detaillierte Naehrwertinformationen fuer ein Produkt ab. Gibt Kalorien, Makros, Vitamine und Nutri-Score mit Bewertung zurueck.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Produkts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the operation and output but does not mention read-only nature, error handling, or any constraints. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 14 words in German, front-loaded with key information. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with one parameter and output schema, description covers purpose and return types. Lacks details on multiple results or error handling, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the single parameter 'barcode' with 'EAN-Barcode des Produkts'. Tool description does not add additional meaning beyond that. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves detailed nutritional information for a product given a barcode, and lists specific return values (calories, macros, vitamins, Nutri-Score). Distinguishes from sibling tools like check_allergens or find_alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when nutritional facts are needed, but does not explicitly provide when-to-use vs alternatives or exclusions. The sibling list provides context but the description lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet alle Zusatzstoffe (E-Nummern) eines Produkts auf. Gibt Risikoklasse und Beschreibung der Zusatzstoffe zurueck.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Produkts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions what is returned but omits critical details like error handling, authentication needs, rate limits, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: one for the action and one for the output. No redundancy, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, output schema exists), the description is mostly complete. It lacks error or edge-case info but covers the essential functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'barcode' is described in the schema. The tool description does not add further meaning or constraints beyond the schema, which meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'listet auf' (lists) and the resource 'Zusatzstoffe (E-Nummern)', and specifies what is returned (risk class and description). It effectively distinguishes this tool from siblings like check_allergens and get_nutrition_facts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, nor any conditions or exclusions. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gibt alle Zertifizierungen und Labels eines Produkts zurueck. Z.B. Bio, Fairtrade, Vegan, Vegetarisch, Halal, Koscher, Glutenfrei.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Produkts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately states the tool's purpose (returns labels/certifications) and is a simple read operation, but it does not mention idempotency, auth requirements, or error handling. The description is straightforward but lacks explicit behavioral traits beyond the core functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and includes concrete examples. Every sentence contributes value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required parameter, existing output schema), the description is fully adequate. It explains what data is returned and provides illustrative examples, leaving no critical gaps for an agent to interpret its operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter barcode has 100% schema description coverage with 'EAN-Barcode des Produkts'. The tool description adds no additional semantic value beyond what the schema already provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns certifications and labels of a product, providing specific examples (Bio, Fairtrade, etc.). This verb+resource combination is distinct from siblings like get_eco_score or get_nutrition_facts, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. There is no provision of conditions, exclusions, or comparisons with sibling tools. The usage context is implied but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ruft vollstaendige Produktinformationen anhand des Barcodes ab. Gibt Name, Marke, Naehrwerte, Allergene und Bewertungen zurueck.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | EAN-Barcode des Produkts (z.B. 3017620422003 fuer Nutella) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states what the tool returns but does not mention side effects, error behavior (e.g., unknown barcode), authentication requirements, or rate limits. This is insufficient for a robust tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the action and listing return fields without any filler. Every word is functional, achieving conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it has a single parameter, an output schema, and sibling tools for specialized queries, the description covers the essential purpose and return values. However, it omits details like read-only behavior or typical use cases, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents the barcode parameter well. The description does not add additional meaning beyond the schema, such as accepted formats or examples. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete product information by barcode and lists return fields (name, brand, etc.). It is specific but does not explicitly differentiate from sibling tools like check_allergens or get_nutrition_facts, which could lead to confusion about when to use this comprehensive lookup vs those specialized tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a barcode is available and full product details are needed, but it provides no explicit guidance on when not to use it or alternatives. For example, it does not mention that check_allergens might be sufficient if only allergens are needed. The guidance is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sucht Lebensmittelprodukte nach Name, Zutat oder Marke. Gibt eine Liste von passenden Produkten mit Grundinformationen zurueck.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Suchbegriff (z.B. "Schokolade", "vegan pasta", "Bio Joghurt") | |
| max_results | No | Anzahl der Ergebnisse (1-20, Standard: 10) | |
| page | No | Seite der Ergebnisse (Standard: 1) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states returns list with basic info but does not disclose pagination behavior, rate limits, authentication needs, or potential side effects. Schema has pagination params but description doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. Front-loaded purpose clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given existence of output schema, description doesn't need to detail return format. Mentions basic info. Could add guidance on when to use vs lookup_product_by_barcode, but overall adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds value by specifying search types (name, ingredient, brand) not in schema, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches food products by name, ingredient, or brand and returns a list with basic info. It distinguishes from siblings like lookup_product_by_barcode (barcode search) and get_nutrition_facts (specific product info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general food product search but does not explicitly provide when to use vs alternatives. No comparison with sibling tools like check_allergens or find_alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_allergensfind_alternativesget_eco_scoreget_nutrition_factsget_product_additivesget_product_labelslookup_product_by_barcodesearch_foodScored across 8 tools
Each tool targets a distinct aspect of food product data: allergens, alternatives, eco-score, nutrition, additives, labels, barcode lookup, and text search. No functional overlap.
All tool names follow a consistent verb_noun pattern in English (check_allergens, find_alternatives, get_eco_score, etc.), providing clear predictability.
8 tools is well-scoped for an Open Food Facts server, covering search, lookup, and various product attributes without being excessive or sparse.
Covers major product information needs (nutrition, eco, allergens, labels, alternatives, search, barcode lookup). Minor gaps like missing product comparison or user contributions are acceptable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
Nutrition MCP — wraps Open Food Facts API (free, no auth)
Open Beauty Facts MCP — Open Beauty Facts API (free, no auth, keyless).
