mcp server

Guardian Engine

Deterministic recipe verification engine — validates AI-generated recipes against master SOPs.

Description as published by the maintainer. Source

• version 1.0.0
• active

active — Most recent push to the repository was 2026-07-20.

What this server can do

7 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.

check_allergens(dish_name, ingredients, restrictions, response_format, check_all_eu_allergens)

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. Use check_all_eu_allergens=True for food labelling (detect all allergens). Use restrictions=['dairy', 'gluten'] to check for specific user allergies. Required: ingredients.

check_safety(candidate_json)

Run master-independent safety checks on a candidate recipe. Works for ANY recipe — no dish resolution, no master SOP required. Checks poultry internal-temperature safety and scans all ingredients for the 14 EU FIC 1169/2011 Annex II allergen groups. The verdict is a deterministic function of (candidate, kb_version_hash) — no LLM involvement. Use this when verify_recipe has no matching master for the dish: the safety layer still applies to every recipe. Returns: Safety envelope: verdict (PASSED/FAILED per the zero-critical policy gate), safe flag, issues found, and the pinned kb_version_hash. Required: candidate_json.

fix_recipe(dish, dish_name, master_json, candidate_json, original_prompt, response_format)

Deterministically repair a candidate recipe against a Guardian master. Verifies the candidate, applies every machine-actionable correction the symbolic engine produced (missing ingredients, quantities, temperatures, durations, cooking media, ingredient substitutions), then re-verifies the result. No LLM is used — the repair is a deterministic function of the candidate recipe and the master ruleset. Findings that need recipe-authoring judgement — adding a whole cooking phase, rewriting step instructions, ingredient-ratio rebalancing — are not auto-applied; they are returned under `patches_skipped`. Allergen findings are never auto-fixed. The response reports the verdict before and after so the caller can see exactly what was resolved. Note: `verdict_after` may still be FAILED when structural changes (e.g. adding a cooking step, rebalancing ingredient ratios) are needed. These require recipe-authoring judgement and are returned under `patches_skipped`. Callers should NOT assume a fixed recipe will pass verification.

get_master(dish_name, response_format)

Return the canonical master recipe for a dish (read-only, no LLM). Enables compare-then-verify agentic loops: fetch the master, diff it against the user's recipe, then call verify_recipe — instead of verifying blind. Pure knowledge-base lookup, no LLM in the hot path. Master content is transparent by default (ADR-009 / ADR-010): exact temperatures, timings, and EU FIC 1169/2011 allergen codes are returned verbatim, never obfuscated. No score is included (ADR-013) — this is reference data, not a verdict. Returns ingredients, steps (technique/temperature/timing/medium), and the EU FIC allergens derived from the required ingredients. Unknown dishes return a structured UNKNOWN_DISH error.

list_dishes(cuisine_filter)

List all available master dishes with rich metadata. Returns: Dictionary with `schema_version` and a `dishes` list. Each dish includes slug, title, cuisine, region, aliases, and complexity.

verify_dietary_claim(claim, candidate_json, response_format)

Verify that a recipe satisfies a dietary claim (vegan, halal, gluten-free, ...). Reuses the existing allergen-detection logic plus a curated forbidden-ingredient map (apps/guardian/knowledge/dietary_claims.yaml). Returns a structured verdict with the specific offending ingredients and a short justification — never a vague paraphrase.

verify_recipe(dish, dish_name, session_id, master_json, operator_id, candidate_json, original_prompt, response_format)

Verify a candidate recipe against a Guardian master recipe. Uses deterministic graph-based verification to check technique, temperature, timing, cooking medium, and required ingredients. **Verdict**: `verdict` is strictly PASSED or FAILED and is policy-driven — any CRITICAL finding fails the recipe; more than 5 WARNINGs also fail. There is no score in the response (ADR-013): gate on `verdict` and explain failures from `findings`. **Field audience**: `issue` is a machine-readable code for programmatic handling — never show it to end users. Use `title` and `suggested_correction` as the user-facing fields. Returns structured JSON by default (machine-actionable findings and patches); response_format="text" renders a human-readable report. Both formats are transparent (ADR-009 / ADR-018): exact values and ingredient names included.

Last successful function declaration observed on 2026-08-13. Source: https://api.kaimeilabs.dev/mcp. We list what the server declared; we do not call any of these functions.

Endpoint status observed on 2026-08-13. Source: https://api.kaimeilabs.dev/mcp.

Signals

These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.

Where to get it

• Repository — https://github.com/kaimeilabs/guardian-api-docs
• Remote endpoint (streamable-http) — https://api.kaimeilabs.dev/mcp