Koskamo

Guardian Engine MCP

A deterministic verification engine that validates AI-generated recipes against master Standard Operating Procedures (SOPs). It catches hallucinations like impossible temperatures or wrong ingredients, returns machine-actionable patches for fixes, and checks for allergens and dietary claims.

Endpoint and access

No sign-in to connect and list tools. Individual tools may still need a vendor account, credentials, or permissions; check the documented prerequisites.

Guardian Engine MCP logo, by Kaimei LabsVendor evidenceStreamable HTTPNo sign-inEndpoint checked 2026-11-06Operated by Kaimei Labs
MCP endpoint (Streamable HTTP)
https://api.kaimeilabs.dev/mcp
Vendor documentation

What its tools do

7 tools, grouped by the hints the server advertises. Hints are self-declared, not verified behavior.

Can change data (1)

7 of 7 have a description · 7 of 7 declare behavior hints · 7 of 7 with parameters document them all

Checks and signals

Each line is separate evidence, not a trust score.

  • Passed Endpoint answered the live check ·
  • Passed Official MCP Registry namespace is tied to kaimeilabs.dev ·
  • Passed Endpoint is on the registry namespace domain ·
  • Availability 1 of 1 checks passed in 30 days

What you can do with it

  • Verify AI-generated recipes against master SOPs
  • Check recipes for allergens and dietary claims
  • Generate machine-actionable patches to fix recipe errors
  • List available master dishes and get master recipe details

Source and maintenance

Vendor evidenceRegistry 1.0.0
Maintenance checked

Protocol and capabilities

Server
Guardian Engine 1.0.0
MCP protocol negotiated in check
2025-11-25
Tools
7 advertised
Resources
0 advertised
Resource templates
0 advertised
Prompts
1 advertised
Server-advertised capabilities
{
  "tools": {
    "listChanged": true
  },
  "logging": {},
  "prompts": {
    "listChanged": true
  },
  "resources": {
    "subscribe": false,
    "listChanged": true
  },
  "extensions": {
    "io.modelcontextprotocol/ui": {}
  },
  "experimental": {}
}

Server-provided instructions

Untrusted server output shown for inspection. It is not Koskamo guidance and is excluded from knowledge search.

Guardian Engine is a deterministic recipe verification service. It validates AI-generated recipes against physics-constrained master SOPs using graph-based logic. Guardian always returns a clear Verdict (PASSED/FAILED) and a list of Findings with severity levels. Output is transparent: findings carry exact ingredient names, temperatures, and durations. verify_recipe and fix_recipe return machine-actionable JSON by default; pass response_format='text' for a human-readable report. OPTIONAL — INCLUDE original_prompt: For safety-aware and personalised feedback, include the user's original cooking request in the original_prompt parameter. Copy the user's exact message — do not paraphrase. Example: if the user said 'make me a spicy vegan rendang', pass that exact string. WHY THIS HELPS: - WITHOUT original_prompt: Guardian returns actionable findings with ingredient names and technique hints. - WITH original_prompt: Guardian additionally checks for safety context (e.g., recipes for infants, pregnant users) and matches findings to dietary needs and flavour preferences.

Tools

7 advertised

verify_recipe
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

verify_recipe input schema
{
  "type": "object",
  "properties": {
    "dish": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Alias for dish_name — for backward compatibility with production clients."
    },
    "dish_name": {
      "type": "string",
      "default": "",
      "description": "Name of the dish to verify against (e.g. 'carbonara', 'rendang', 'roast-chicken', 'confit', 'cheesecake', 'kung-pao', 'fried-chicken', 'brisket', 'wellington', 'cheese-souffle'). Use list_dishes() to see all available recipes and their aliases."
    },
    "session_id": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional session ID to track an agent's improvement loop across multiple attempts."
    },
    "master_json": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "object",
          "additionalProperties": true
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional user-supplied master SOP to verify against (BYO master, ADR-018), as a JSON string or object using the same schema as catalog masters (dish_name, steps[], required_ingredients[]; see get_master() for a live example). When provided, the bundled catalog is bypassed — the candidate is checked against YOUR spec — and dish_name may be omitted. The response pins the spec via master_hash (sha256) and master_source='user' so the verdict is replayable."
    },
    "operator_id": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional audit identifier for the calling operator (letters, digits, hyphens; max 64 chars). Tags the verification in the tamper-evident log and compliance record. Defaults to 'anonymous'."
    },
    "candidate_json": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "object",
          "additionalProperties": true
        }
      ],
      "default": "",
      "description": "The full candidate recipe as a JSON string or object. Expected schema: {\"title\": \"<string>\", \"cuisine\": \"<string>\", \"serves\": <int>, \"ingredients\": [{\"name\": \"<string>\", \"quantity\": \"<string>\"}], \"steps\": [{\"step_number\": <int>, \"title\": \"<string>\", \"instruction_english\": \"<string>\", \"technique\": \"<string>\", \"estimated_temperature_c\": <number or [min, max]>, \"duration_minutes\": <number or [min, max]>, \"cooking_medium\": \"<string>\"}]}"
    },
    "original_prompt": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "RECOMMENDED for best results. Include the user's original cooking request. Copy the user's exact message that triggered this recipe (e.g., 'Make me a spicy vegan rendang' or 'Generate a traditional carbonara, but healthier'). WITHOUT this parameter: Guardian returns actionable findings with specific ingredient names and technique details — enough to fix most recipes. WITH this parameter: Guardian additionally activates safety context awareness (e.g., flagging honey for infants, raw egg for pregnant users) and personalised feedback matched to dietary needs and flavour preferences. Include it when the user's context matters for safety or personalisation."
    },
    "response_format": {
      "type": "string",
      "default": "json",
      "description": "Response format: 'json' (default — machine-actionable verdict, findings, and patches) or 'text' (human-readable report)."
    }
  },
  "additionalProperties": false
}
verify_recipe output schema
{
  "type": "object",
  "required": [
    "result"
  ],
  "properties": {
    "result": {
      "type": "string"
    }
  },
  "x-fastmcp-wrap-result": true
}
verify_recipe annotations
{
  "readOnlyHint": true,
  "idempotentHint": true
}
fix_recipe
Advertised by the server during the last successful anonymous check.

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.

fix_recipe input schema
{
  "type": "object",
  "properties": {
    "dish": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Alias for dish_name — for backward compatibility with production clients."
    },
    "dish_name": {
      "type": "string",
      "default": "",
      "description": "Name of the dish to repair against (e.g. 'carbonara', 'rendang', 'roast-chicken'). Use list_dishes() to see all available recipes and their aliases."
    },
    "master_json": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "object",
          "additionalProperties": true
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional user-supplied master SOP to repair against (BYO master, ADR-018), same schema as catalog masters. When provided, the catalog is bypassed and dish_name may be omitted; patches (including suggested_step templates) are built from THIS spec."
    },
    "candidate_json": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "object",
          "additionalProperties": true
        }
      ],
      "default": "",
      "description": "The full candidate recipe as a JSON string or object — same schema as verify_recipe's candidate_json (title, cuisine, ingredients[], steps[])."
    },
    "original_prompt": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional. The user's original cooking request, used only for safety-context awareness during verification. Does not change which fixes are applied."
    },
    "response_format": {
      "type": "string",
      "default": "json",
      "description": "Response format: 'json' (default — includes the full fixed_recipe object) or 'text' (human-readable report)."
    }
  },
  "additionalProperties": false
}
fix_recipe output schema
{
  "type": "object",
  "required": [
    "result"
  ],
  "properties": {
    "result": {
      "type": "string"
    }
  },
  "x-fastmcp-wrap-result": true
}
fix_recipe annotations
{
  "readOnlyHint": false,
  "idempotentHint": true
}
list_dishes
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

list_dishes input schema
{
  "type": "object",
  "properties": {
    "cuisine_filter": {
      "type": "string",
      "default": "",
      "description": "Optional cuisine to filter by. Case-insensitive exact match against the dish's cuisine field. Valid values: italian | french | spanish | british | thai | chinese | indian | indonesian | japanese | malaysian | korean | mexican | american | moroccan | turkish | levantine. Leave empty to return all available dishes."
    }
  },
  "additionalProperties": false
}
list_dishes output schema
{
  "type": "object",
  "additionalProperties": true
}
list_dishes annotations
{
  "readOnlyHint": true,
  "idempotentHint": true
}
get_master
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

get_master input schema
{
  "type": "object",
  "properties": {
    "dish_name": {
      "type": "string",
      "default": "",
      "description": "Name or alias of the dish to fetch the canonical master recipe for (e.g. 'carbonara', 'spaghetti bolognese', 'angel food cake'). Alias resolution and slug normalisation are applied. Use list_dishes() to browse."
    },
    "response_format": {
      "type": "string",
      "default": "json",
      "description": "Response format: 'json' (default, structured) or 'text' (human-readable summary)."
    }
  },
  "additionalProperties": false
}
get_master output schema
{
  "type": "object",
  "required": [
    "result"
  ],
  "properties": {
    "result": {
      "type": "string"
    }
  },
  "x-fastmcp-wrap-result": true
}
get_master annotations
{
  "readOnlyHint": true,
  "idempotentHint": true
}
check_safety
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

check_safety input schema
{
  "type": "object",
  "required": [
    "candidate_json"
  ],
  "properties": {
    "candidate_json": {
      "type": "string",
      "description": "The full candidate recipe as a JSON string. Checked for poultry internal temperature safety (≥74°C) and EU FIC 1169 allergen presence."
    }
  },
  "additionalProperties": false
}
check_safety output schema
{
  "type": "object",
  "additionalProperties": true
}
check_safety annotations
{
  "readOnlyHint": true,
  "idempotentHint": true
}
check_allergens
Advertised by the server during the last successful anonymous check.
Advertised read-only

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_allergens input schema
{
  "type": "object",
  "required": [
    "ingredients"
  ],
  "properties": {
    "dish_name": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional dish name for reporting context."
    },
    "session_id": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional session identifier so repeated checks are stitched into one trajectory."
    },
    "ingredients": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "List of ingredient names (freeform or canonical IDs). Examples: ['butter', 'wheat_flour', 'eggs', 'peanut_butter']"
    },
    "operator_id": {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Optional audit identifier for the calling operator (letters, digits, hyphens; max 64 chars). Tags the check in the telemetry log. Defaults to 'anonymous'."
    },
    "restrictions": {
      "anyOf": [
        {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "description": "Allergen 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_format": {
      "type": "string",
      "default": "json",
      "description": "Response format: 'json' (default) for the machine-actionable payload, or 'text' for a human-readable report."
    },
    "check_all_eu_allergens": {
      "type": "boolean",
      "default": false,
      "description": "If True, scans for all 14 EU Annex II allergens regardless of restrictions list. Use this for food labelling (declare all allergens present)."
    }
  },
  "additionalProperties": false
}
check_allergens output schema
{
  "type": "object",
  "required": [
    "result"
  ],
  "properties": {
    "result": {
      "anyOf": [
        {
          "type": "object",
          "additionalProperties": true
        },
        {
          "type": "string"
        }
      ]
    }
  },
  "x-fastmcp-wrap-result": true
}
check_allergens annotations
{
  "readOnlyHint": true,
  "idempotentHint": true
}
verify_dietary_claim
Advertised by the server during the last successful anonymous check.
Advertised read-only

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_dietary_claim input schema
{
  "type": "object",
  "properties": {
    "claim": {
      "type": "string",
      "default": "",
      "description": "Dietary claim to verify: vegan | vegetarian | gluten_free | dairy_free | nut_free | halal | kosher."
    },
    "candidate_json": {
      "type": "string",
      "default": "",
      "description": "Recipe JSON string (CandidateRecipe schema). Expected shape: {\"title\": \"...\", \"ingredients\": [{\"name\": \"...\"}, ...], \"steps\": [...]}. Only the ingredient list is required for dietary verification."
    },
    "response_format": {
      "type": "string",
      "default": "text",
      "description": "Response format: 'text' (default, human-readable) or 'json' (machine-actionable)."
    }
  },
  "additionalProperties": false
}
verify_dietary_claim output schema
{
  "type": "object",
  "required": [
    "result"
  ],
  "properties": {
    "result": {
      "type": "string"
    }
  },
  "x-fastmcp-wrap-result": true
}
verify_dietary_claim annotations
{
  "readOnlyHint": true,
  "idempotentHint": true
}

Prompts

1 advertised

verify_recipe_prompt

Advertised by the server during the last successful anonymous check.

Provides instructions and a template for an AI agent to verify a recipe. Args: dish: The name of the dish to verify (e.g. 'carbonara', 'rendang').

dish
Provide as a JSON string matching the following schema: {"type":"string"}

Resources

0 advertised

No resource definitions available.

90-day uptime

A lightweight connection check about every six hours, sampled on hosts with many listings. It shows the server answered, not that its tools work.

Too few checks for a percentage yet (1 of 1 answered).

  1. 2026-11-07: 1 of 1 checks answered

30-day availability

Aggregated from read-only remote checks; this is not a tool-execution or security guarantee.

Successful checks
1 of 1 (100%)
Average latency
1508 ms
95th percentile latency
1508 ms

Maintenance history

Public check and source-refresh events. Editorial and ownership records remain private.

  • · probe · passed · 1508 ms · metadata changed · 7 tool(s), 0 resource(s), 0 resource template(s), 1 prompt(s)

Connect from your client

Each snippet registers the same endpoint; pick the client you use.

This server is operated by the named third party. Listing and endpoint checks are not an endorsement or a security audit. Review the operator's permissions, terms, and data handling before connecting. How listings are checked and corrected.

Claude Code

Run this once in a terminal. It registers the remote server. Use --scope project to write .mcp.json for the repo.
Claude Code configuration
claude mcp add --transport http guardian-engine-mcp https://api.kaimeilabs.dev/mcp

Codex

Run this once. Codex stores MCP servers in ~/.codex/config.toml (or .codex/config.toml in a trusted project).
Codex configuration
codex mcp add guardian-engine-mcp --url https://api.kaimeilabs.dev/mcp

Cursor

Merge this server into .cursor/mcp.json in your project, then enable guardian-engine-mcp in your MCP settings.
Cursor configuration
{
  "mcpServers": {
    "guardian-engine-mcp": {
      "url": "https://api.kaimeilabs.dev/mcp"
    }
  }
}

Cline

Merge this into cline_mcp_settings.json (Cline → MCP Servers → Configure).
Cline configuration
{
  "mcpServers": {
    "guardian-engine-mcp": {
      "type": "streamableHttp",
      "url": "https://api.kaimeilabs.dev/mcp",
      "disabled": false
    }
  }
}

VS Code

Merge this server into .vscode/mcp.json. Use MCP: List Servers to start guardian-engine-mcp and inspect its tools.
VS Code configuration
{
  "servers": {
    "guardian-engine-mcp": {
      "type": "http",
      "url": "https://api.kaimeilabs.dev/mcp"
    }
  }
}

Gemini CLI

Run this once. It writes .gemini/settings.json in the current project; pass --scope user for ~/.gemini/settings.json.
Gemini CLI configuration
gemini mcp add --transport http guardian-engine-mcp https://api.kaimeilabs.dev/mcp

Claude Desktop

Open Claude Settings > Connectors > Add custom connector, enter this server URL and enable it for the conversation. This is a manual remote-connector handoff, not a desktop JSON configuration.
Claude Desktop configuration
https://api.kaimeilabs.dev/mcp

Windsurf

Merge this into ~/.codeium/windsurf/mcp_config.json, then refresh MCP in Cascade. Windsurf remote servers use serverUrl, not url.
Windsurf configuration
{
  "mcpServers": {
    "guardian-engine-mcp": {
      "serverUrl": "https://api.kaimeilabs.dev/mcp"
    }
  }
}

Let your agent find its tools

Find servers like Guardian Engine MCP from your agent. Add Koskamo once to search the index for endpoints, access requirements, and client setup. Public discovery needs no key.

Do you run Guardian Engine MCP?

Prove ownership with a DNS record, a well-known file, or your Official MCP Registry entry, and your edits publish immediately. Proofs are re-checked weekly; admins can still hide or remove a listing.

Claim this listing