Skip to main content
Glama

openfoodfacts-mcp-server

by io.github.cyanheads

Compare Food Products Side-by-Side

off_compare_products
Read-onlyIdempotent

Side-by-side nutrition and scoring comparison for 2–10 products by barcode. Returns a normalized table of energy (kcal/100g), fat, saturated fat, sugars, salt, protein, fiber, Nutri-Score, NOVA group, and Green-Score. Designed for "which of these cereals is healthiest?" or "compare these pasta brands" workflows. Missing nutrition data for any product is preserved as absent — comparisons are not imputed. A batch is not all-or-nothing: barcodes that resolve are returned even when others fail, with confirmed-missing barcodes listed in not_found and failed fetches listed separately in failed. Scores carry regional formula caveats. Data under ODbL 1.0 — cite Open Food Facts in downstream use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
barcodesYes2–10 barcodes to compare, returned as one row each in input order. Example: ["3017620422003", "7622210100146"].

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
failedNoBarcodes whose fetch failed, with the per-barcode reason. Absent when every fetch completed. A barcode listed here is unknown, not absent from Open Food Facts — retry it with off_get_product before concluding anything about the product.
productsNoComparison rows in input order — one per barcode whose fetch completed, whether or not a record exists. Barcodes whose fetch failed have no row here; they appear in failed.
not_foundNoBarcodes Open Food Facts answered for, confirming no contributor record exists. Not an error — the product may exist but not yet be entered. Never used for a fetch that failed.
succeededNoNumber of barcodes that resolved to a found product.

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly, openWorld, and idempotent hints, the description discloses key behaviors: missing data is preserved (not imputed), batches are not all-or-nothing with separate handling of not_found and failed barcodes, regional formula caveats exist, and attribution is required under ODbL 1.0. This adds substantial value over the annotations.

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-organized and front-loaded with the core purpose, then covers exceptions, licensing, and caveats. It is slightly longer than necessary but each sentence adds distinct information, so it earns a 4 rather than a 5.

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

Completeness5/5

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

The description covers purpose, parameter constraints, error behavior, regional caveats, and licensing. An output schema exists, so return-value details are not required in the description. All essential information for correctly invoking the tool is present, and sibling tools provide further context.

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

Parameters3/5

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

Schema description coverage is 100% and already describes the barcodes parameter including min/max and input-order behavior. The description repeats the input-order detail and adds output-field information, but this does not clarify the parameter's semantics beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool compares 2–10 products side-by-side by barcode, lists the specific nutrition and scoring fields, and gives concrete example workflows ('which of these cereals is healthiest?'). It distinguishes itself from siblings: off_get_product (single product), off_search_products (search), off_browse_taxonomy (browse).

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

Usage Guidelines4/5

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

The description provides explicit example use cases and explains the batch behavior (partial success, not_found vs failed). It does not explicitly name alternative tools for single-product lookups, but the comparison workflow is clearly the intended use. The distinction from siblings is implied rather than stated, so it falls short of a 5.

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

All openfoodfacts-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: taxonomy resolution, product search, product details, and comparative analysis. No overlap or ambiguity exists between them.

Naming Consistency5/5

All tools follow a consistent 'off_verb_noun' pattern with snake_case (browse_taxonomy, compare_products, get_product, search_products). The naming is predictable and immediately conveys the action and target.

Tool Count5/5

With only 4 tools, the server stays well-scoped and avoids redundancy. This is an ideal size for a focused read-only API covering search, fetch, compare, and taxonomy lookup.

Completeness5/5

For a read-only crowd-sourced database, the toolset covers all essential workflows: discovering products (search), retrieving full details (get), comparing alternatives (compare), and resolving filter values (browse_taxonomy). No critical gaps are apparent.

Resources