# Guardian Engine

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

- name: dev.kaimeilabs/guardian-engine
- version: 1.0.0
- connection class: R0 (autonomous)
- trust: 85/100
- quality: 82/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/dev.kaimeilabs%2Fguardian-engine
- tools: https://api.protogrid.dev/v1/servers/dev.kaimeilabs%2Fguardian-engine/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "guardian-engine": {
      "type": "http",
      "url": "https://api.kaimeilabs.dev/mcp"
    }
  }
}
```


## Trust

- hygiene: 100
- liveness: 98
- freshness: 45
- provenance: 90
- drivers: +repository +namespace-matches-repo +dns-namespace +reachable +uptime-96% -stale-235d
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 82/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 79 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 1 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 7 of 7 tools declare readOnlyHint or destructiveHint
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: list_dishes (destructiveHint, openWorldHint); check_safety (destructiveHint, openWorldHint); verify_dietary_claim (destructiveHint, openWorldHint); …
- pass `tools.token_cost`: about 3,292 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: no tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 7, about 3,292 tokens to load them all
- tool set hash: 647e8c345d42b3a33a49f57637df5927
- badge: [![protogrid quality](https://protogrid.dev/badge/dev.kaimeilabs/guardian-engine.svg)](https://protogrid.dev/servers/dev.kaimeilabs/guardian-engine)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

_No tool definition changes recorded._

## Remotes

- https://api.kaimeilabs.dev/mcp (streamable-http, auth none, reachable true, uptime30d 0.95652175)

## Packages

_none_

## Tools (7)

- `check_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 — 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.
- `check_safety`: 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.
- `fix_recipe`: 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`: 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`: List all available master dishes with rich metadata.

This is a browse/discovery step, not the verification itself — after picking
a dish, call verify_recipe(dish_name=<slug>, candidate_json=<your recipe>) to
actually check a candidate against it (or fix_recipe to auto-repair it).

Returns:
    Dictionary with `schema_version`, a `dishes` list (slug, title, cuisine,
    region, aliases, complexity per dish), and a `next_step` hint describing
    how to proceed to verification.
- `verify_dietary_claim`: 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`: 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.