Guardian Engine
Server Details
Deterministic recipe verification engine — validates AI-generated recipes against master SOPs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- kaimeilabs/guardian-api-docs
- GitHub Stars
- 0
- Server Listing
- guardian-engine
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 6 of 6 tools scored. Lowest: 3.8/5.
Each tool has a clearly distinct purpose: allergen checking, recipe repair, master retrieval, dish listing, dietary claim verification, and recipe verification. No two tools overlap in functionality, and the descriptions clarify any potential confusion.
All tool names follow a consistent verb_noun pattern using lowercase and underscores (e.g., check_allergens, fix_recipe, get_master). This makes the tool set predictable and easy to navigate.
With 6 tools, the set is well-scoped for the domain of recipe verification and mastery. Each tool covers a necessary operation without redundancy or bloat, and the count feels natural for the described purpose.
The tool set covers the core workflows: listing dishes, retrieving master recipes, verifying recipes, checking allergens, verifying dietary claims, and fixing recipes. A minor gap is the lack of a search tool for dishes, but list_dishes returns all dishes with metadata, which is sufficient for most use cases.
Available Tools
6 toolscheck_allergensARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| dish_name | No | Optional dish name for reporting context. | |
| ingredients | Yes | List of ingredient names (freeform or canonical IDs). Examples: ['butter', 'wheat_flour', 'eggs', 'peanut_butter'] | |
| restrictions | No | 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 | No | Response format: 'text' (default) or 'json'. Use 'json' for machine-actionable output. | text |
| check_all_eu_allergens | No | If True, scans for all 14 EU Annex II allergens regardless of restrictions list. Use this for food labelling (declare all allergens present). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description adds that safety verdict is deterministic with no LLM involvement, and explains the return format: 'detailed audit trace mapping each ingredient to its EU Annex II allergen group with entry numbers and labels.' No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short paragraphs. First sentence states purpose, second explains output, third gives determinism guarantee, then two clear usage directives. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description needn't detail return structure. Covers main function, parameter usage, behavioral traits, and provides examples. For a tool with 5 parameters and full schema coverage, this description is complete and leaves no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions already provide basic meaning. The tool description adds value by listing valid restriction IDs and clarifying the interaction between restrictions and check_all_eu_allergens (if None and check_all_eu_allergens=True, reports all). Only minor missed opportunity: could specify that dish_name is optional for context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with specific verb 'check' and resource 'ingredients for EU FIC 1169/2011 allergen compliance'. Clearly distinguishes from sibling tools like verify_dietary_claim or fix_recipe by focusing on allergen compliance with a deterministic audit trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use check_all_eu_allergens=True for food labelling' and 'Use restrictions=... for specific user allergies.' Clearly states when to use each parameter and the deterministic nature of the tool, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fix_recipeAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| dish | No | Alias for dish_name — for backward compatibility with production clients. | |
| dish_name | No | Name of the dish to repair against (e.g. 'carbonara', 'rendang', 'roast-chicken'). Use list_dishes() to see all available recipes and their aliases. | |
| candidate_json | No | The full candidate recipe as a JSON string or object — same schema as verify_recipe's candidate_json (title, cuisine, ingredients[], steps[]). | |
| original_prompt | No | Optional. The user's original cooking request, used only for safety-context awareness during verification. Does not change which fixes are applied. | |
| response_format | No | Response format: 'text' (default) or 'json'. Use 'json' to receive the full fixed_recipe object. | text |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides rich behavioral context beyond annotations: deterministic, no LLM used, only machine-actionable corrections applied, allergen findings never auto-fixed, and patches_skipped for judgement-requiring items. It also discloses that the result may still fail verification. This fully informs the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main action in the first sentence, followed by specific details about what is and isn't fixed, and a final note about verdict. While it is somewhat long, every sentence adds value and is not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema available), the description covers all essential aspects: deterministic repair, types of corrections, exclusions (allergens, structural changes), and behavior when verification fails. The availability of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters. The description adds minimal extra meaning, though it mentions using list_dishes() for dish_name and notes candidate_json follows the same schema as verify_recipe. This is helpful but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deterministically repair a candidate recipe against a Guardian master.' It specifies the action (repair), the resource (candidate recipe), and the nature (deterministic, no LLM). It distinguishes itself from sibling tools like verify_recipe (which likely only verifies) by describing the repair process and what is auto-applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when automated, machine-actionable corrections are needed. It notes what is not auto-applied (e.g., structural changes requiring authoring judgement) and warns that verdict_after may still be FAILED. However, it does not explicitly name alternatives or contrast with verify_recipe, and lacks 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_masterARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| dish_name | No | 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 | No | Response format: 'json' (default, structured) or 'text' (human-readable summary). | json |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: no LLM, pure knowledge-base, transparency policies (ADR-009/010), exact data returned, no score, and error format. No contradiction with readOnlyHint/idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose, well-structured paragraphs, each sentence adds value. Slightly verbose in third paragraph but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, behavior, parameters, return content, and error handling. Output schema handles structure, so description is complete for a lookup tool with 2 optional params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning for dish_name (alias resolution, slug normalization, suggestion to use list_dishes) beyond schema description. Response_format gets less added value. Baseline 3 increased to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the canonical master recipe for a dish (read-only, no LLM)', distinguishing it from sibling tools like verify_recipe by mentioning compare-then-verify loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: 'fetch the master, diff it against the user's recipe, then call verify_recipe — instead of verifying blind', and notes structured error for unknown dishes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dishesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cuisine_filter | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. Description adds return structure details but no behavioral traits beyond that. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 3 lines. Purpose is front-loaded. Every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional filter parameter and an output schema, the description covers the purpose and basic return structure. Could mention empty results or default behavior, but fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully describes the cuisine_filter parameter. Description does not mention it, so no added value beyond schema. Baseline score due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all available master dishes with rich metadata. Distinguishes from sibling tools that fix or verify recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not provide explicit guidance on when to use versus alternatives. Usage is implied as the default listing tool, but no conditions or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_dietary_claimARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | No | Dietary claim to verify: vegan | vegetarian | gluten_free | dairy_free | nut_free | halal | kosher. | |
| candidate_json | No | Recipe JSON string (CandidateRecipe schema). Expected shape: {"title": "...", "ingredients": [{"name": "..."}, ...], "steps": [...]}. Only the ingredient list is required for dietary verification. | |
| response_format | No | Response format: 'text' (default, human-readable) or 'json' (machine-actionable). | text |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable context: returns a structured verdict with specific offending ingredients and a short justification, never a vague paraphrase. This goes beyond annotations in describing output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameters are fully described in the schema, the description adequately explains the tool's functionality and output. It could be more complete by mentioning any limitations or edge cases, but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add detail to the parameters beyond what is in the schema. It focuses on the output rather than parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the resource 'dietary claim' with specific examples (vegan, halal, gluten-free). It distinguishes from sibling tool 'check_allergens' by mentioning reuse of allergen-detection logic and a curated forbidden-ingredient map, making the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for dietary claims and builds on allergen logic, but it does not explicitly state when to use it instead of 'check_allergens' or other siblings. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_recipeARead-onlyIdempotentInspect
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 a formatted text report or structured JSON (response_format="json"). In Oracle Mode (default), proprietary data is protected — exact values are replaced with directional hints.
| Name | Required | Description | Default |
|---|---|---|---|
| dish | No | Alias for dish_name — for backward compatibility with production clients. | |
| dish_name | No | 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 | No | Optional session ID to track an agent's improvement loop across multiple attempts. | |
| operator_id | No | 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 | No | 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 | No | 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 | No | Response format: 'text' (default) or 'json'. Use 'json' for machine-actionable patches. | text |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively details behavior beyond annotations: verdict policy (PASSED/FAILED based on CRITICALs and WARNINGs), field audience (issue vs user-facing fields), Oracle Mode protection, and return format options. Annotations only indicate read-only and idempotent; the description adds rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold section headers, but is somewhat verbose. It conveys all necessary information without excessive redundancy, though some details could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, policy-driven verdict, Oracle Mode, multiple output formats), the description covers all key aspects. The output schema exists, so the description appropriately focuses on behavior and decision logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the input schema (100% coverage). The description adds substantial value: it explains the purpose of original_prompt (safety/personalisation), provides examples for dish_name and a schema for candidate_json, and details the audit use of operator_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: verifying a candidate recipe against a Guardian master recipe. It lists specific aspects checked (technique, temperature, timing, etc.) and distinguishes itself from sibling tools like check_allergens or fix_recipe by focusing on overall verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its clear purpose, but lacks explicit guidance on when to prefer this tool over siblings. It does recommend including original_prompt for best results, providing some usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.