Nutriscan MCP connector

compare_products

Read-only

Compare two Open Food Facts products by barcode on nutrients per 100 g, Nutri-Score, NOVA, and allergens. Shows which side is numerically lower; results are not dietary advice.

Instructions

Compare two Open Food Facts products by barcode on nutrients per 100 g, Nutri-Score, NOVA, and allergens. barcode_a and barcode_b are returned as a and b. Says which side is numerically lower. A lower number is not always better (protein and fiber are often desirable). Not dietary advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "barcode_a": "<barcode_a>",
      "barcode_b": "<barcode_b>"
    },
    "name": "compare_products"
  }
}

Input Schema

Name	Required	Description	Default
`barcode_a`	Yes	First product barcode.
`barcode_b`	Yes	Second product barcode. Must differ from barcode_a.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint true), so the description's added detail is the real contribution: it discloses that inputs come back as 'a' and 'b', that it reports which side is numerically lower, and that lower is not inherently better. The 'not dietary advice' disclaimer is a genuine usage-boundary disclosure, though error/not-found behavior is unstated.

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?

Four short sentences with the core comparison and its four comparison dimensions front-loaded, followed by output mapping and then the interpretation caveat. Each sentence carries distinct information, though the phrasing is slightly clipped ('Says which side is numerically lower') rather than fully polished.

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?

For a two-parameter read-only tool with no output schema, the description covers what is compared, how inputs surface in the result, the directionality of the comparison, and an interpretation warning. The main remaining gap is behavior on invalid or missing barcodes, which an agent would need to handle.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by explaining that barcode_a and barcode_b map to output keys 'a' and 'b' — a mapping the schema cannot convey. It does not restate the schema's requirement that the two barcodes differ, which is fine since that is already documented.

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?

States a specific verb (compare) plus the exact resource and scope: two Open Food Facts products by barcode, across nutrients per 100 g, Nutri-Score, NOVA, and allergens. That makes it unmistakable against single-item siblings like barcode_lookup, nutrients_per_serving, and nutriscore_nova without any schema inspection.

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

Usage Guidelines3/5

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

Usage is implied by the two-barcode comparison framing, and the 'lower number is not always better' caveat usefully guards against misreading results. However, it never says when to prefer this over the sibling lookups, nor what to do if a barcode is unknown or the products are incomparable.

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

Deploy Server