Skip to main content
Glama

Check nutrition claims against GB/EU and US rules

check_claim

For a RAW or minimally-processed whole food, report which nutrition claims ("source of iron", "high in vitamin C", "high fibre") the published data supports under GB/EU rules (15%/30% of NRV per 100 g, Reg. 1924/2006) and US rules (10-19%/20% of DV per RACC, 21 CFR 101.54) — and, uniquely, flag where that answer DEPENDS ON WHICH national food-composition table was used, since the eleven tables reconciled here disagree on the same food by a median of 1.63x. Applies to claims wherever they appear, including websites and advertising (Reg. 1924/2006 Art. 1(2)), not only packaging. NOT valid for cooked or manufactured products — their composition depends on recipe and processing. Screening only: under Art. 5(1)(b)(i) the nutrient must be in THE FINAL PRODUCT, so a supported claim still needs an analysis of the producer's own produce. Never treat this as a way to pick a source that qualifies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
foodYesFood slug or name — e.g. "banana", "brazil-nuts".
marketNoWhich rules to apply. Default "both" — the divergence is usually the point.
nutrientNoOptional: check one nutrient only, e.g. "potassium".
preparationNoMust be "raw" (the default). This tool holds raw and minimally-processed commodity data only and REFUSES anything else, because cooking changes composition in both directions — vitamin C and folate are destroyed while minerals concentrate as water is lost. If the food you are asking about has been cooked, juiced, or made into a product, do not call this tool: its answer would not describe your product, and a nutrition claim is a legal statement about the product actually sold.
only_permittedNoOptional: return only claims the data supports, dropping the ones that fail.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and meets it thoroughly: it discloses refusal behavior for non-raw foods, legal scope beyond packaging, screening-only limits, and the requirement that claims ultimately need analysis of the producer's own product. This goes well beyond a typical 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.

Conciseness4/5

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

The description is dense and every clause earns its place, but it is a single long paragraph with legal citations and multiple caveats. It is front-loaded with the core purpose and is still readable, though it would benefit from clearer structural separation.

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 complex tool with no output schema and no annotations, the description is very complete: it covers scope, exclusions, legal basis, and screening caveats. A small gap is the ambiguity between 'raw or minimally-processed' in the description and the preparation parameter only allowing 'raw'.

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 coverage is 100% and the schema already documents each parameter thoroughly, including the 'raw' restriction and the 'both' default. The description adds legal thresholds and table-divergence context, but not additional parameter-level meaning beyond what the schema already provides.

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 uses a specific verb-resource pair: 'report which nutrition claims ... the published data supports under GB/EU rules ... and US rules'. It also states its unique differentiator — flagging dependence on which national food-composition table was used — which separates it from generic nutrient lookup tools.

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?

It explicitly states when to use the tool ('For a RAW or minimally-processed whole food') and when not to ('NOT valid for cooked or manufactured products', 'do not call this tool'). It also warns it is screening-only and must not be used to pick a qualifying source, but it does not name alternative sibling tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.