Skip to main content
Glama

Guardian Engine

by dev.kaimeilabs

check_allergens

Read-onlyIdempotent

Check ingredients for EU FIC 1169/2011 allergen compliance.

Returns a detailed audit trace mapping each ingredient to its EU Annex II allergen group with entry numbers and labels. The safety verdict is deterministic — no LLM involvement in the decision — and is pinned by the returned kb_version_hash.

Use check_all_eu_allergens=True for food labelling (detect all allergens). Use restrictions=['dairy', 'gluten'] to check for specific user allergies. Supplying neither runs the full 14-group Annex II scan and sets defaulted_to_full_scan — the tool never reports "safe" without checking.

is_safe answers "was a supplied restriction violated?"; declared_allergens answers "what is actually present?". Read both.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dish_nameNoOptional dish name for reporting context.
session_idNoOptional session identifier so repeated checks are stitched into one trajectory.
ingredientsYesList of ingredient names (freeform or canonical IDs). Examples: ['butter', 'wheat_flour', 'eggs', 'peanut_butter']
operator_idNoOptional audit identifier for the calling operator (letters, digits, hyphens; max 64 chars). Tags the check in the telemetry log. Defaults to 'anonymous'.
restrictionsNoAllergen group IDs to check against user restrictions. Valid IDs: gluten, crustaceans, eggs, fish, peanuts, soy, dairy, tree_nuts, celery, mustard, sesame, sulphites, lupin, molluscs. If None and check_all_eu_allergens=True, reports all detected allergens.
response_formatNoResponse format: 'json' (default) for the machine-actionable payload, or 'text' for a human-readable report.json
check_all_eu_allergensNoIf True, scans for all 14 EU Annex II allergens regardless of restrictions list. Use this for food labelling (declare all allergens present).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description reveals critical behavior: the safety verdict is deterministic with no LLM involvement, it is pinned by kb_version_hash, is_safe vs declared_allergens have distinct meanings, and it never reports 'safe' without checking. This is substantial behavioral disclosure.

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 compact and front-loaded with the primary purpose. Each sentence adds substantive information (determinism, field semantics, parameter modes), but it is denser than strictly necessary and could be lightly restructured for scannability.

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?

Given the output schema exists and the annotations cover read-only/idempotent behavior, the description covers param mode choices, default behavior, deterministic semantics, and the meaning of key result fields. There are no critical gaps for as an agent to call this tool correctly.

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, but the description adds meaningful interoperability: it explains how check_all_eu_allergens and restrictions interact, and the default 'full 14-group scan' behavior with defaulted_to_full_scan. This goes beyond the schema's individual parameter descriptions.

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

Purpose4/5

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

The description clearly states a specific verb and resource: 'Check ingredients for EU FIC 1169/2011 allergen compliance.' It is unambiguous about what the tool does, but it does not explicitly differentiate itself from sibling tools like check_safety or verify_dietary_claim, so it misses the top score.

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 gives explicit guidance on parameter usage: 'Use check_all_eu_allergens=True for food labelling' and 'Use restrictions=[...] to check for specific user allergies,' plus the default behavior when neither is supplied. This is clear context, but it doesn't mention when to choose this tool over sibling tools, so no exclusions are given.

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

All Guardian Engine 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
Disambiguation3/5

check_allergens, check_safety, and verify_dietary_claim all involve allergen scanning, so an agent could plausibly select the wrong one depending on whether it needs an ingredient audit, a master-independent safety envelope, or a dietary claim. The descriptions contain helpful usage hints, but the boundaries between the allergen-focused checks are not crisply defined.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun convention: check_allergens, check_safety, fix_recipe, get_master, list_dishes, verify_dietary_claim, verify_recipe. There is no mixing of casing styles or vague generic verb naming.

Tool Count5/5

Seven tools is well-scoped for a recipe verification engine: discovery, reference retrieval, verification, repair, and independent safety checks each have a dedicated entry point. No tool feels redundant or unnecessary, and the set is small enough for an agent to navigate easily.

Completeness4/5

The core workflow is covered end-to-end: list_dishes and get_master enable discovery and reference comparison, verify_recipe and fix_recipe handle master-based verification and repair, and check_safety, check_allergens, and verify_dietary_claim cover independent safety checks. Minor gaps exist, such as the lack of master-authoring/update tools and master-independent temperature safety being limited to poultry, but agents can work around these.

Resources