A
licenseNot graded
qualityA
maintenanceDeterministic verification for AI-generated analysis. Reconciliation, consistency and Excel-integrity checks that stop the line when the numbers don't add up.
1
MIT
Guardian Engine
Server Details
Deterministic recipe verification engine — validates AI-generated recipes against master SOPs.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- kaimeilabs/guardian-api-docs
- GitHub Stars
- 0
- Server Listing
- guardian-engine
Available Tools
7 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 — 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dish_name | No | Optional dish name for reporting context. | |
| session_id | No | Optional session identifier so repeated checks are stitched into one trajectory. | |
| ingredients | Yes | List of ingredient names (freeform or canonical IDs). Examples: ['butter', 'wheat_flour', 'eggs', 'peanut_butter'] | |
| operator_id | No | Optional audit identifier for the calling operator (letters, digits, hyphens; max 64 chars). Tags the check in the telemetry log. Defaults to 'anonymous'. | |
| 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: 'json' (default) for the machine-actionable payload, or 'text' for a human-readable report. | json |
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
check_safetyARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| candidate_json | Yes | The full candidate recipe as a JSON string. Checked for poultry internal temperature safety (≥74°C) and EU FIC 1169 allergen presence. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond the readOnlyHint and idempotentHint annotations: the verdict is 'a deterministic function of (candidate, kb_version_hash) — no LLM involvement' and the checks are precisely enumerated (poultry ≥74°C, 14 allergen groups). It also details the return envelope components, adding valuable transparency about outputs.
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 well-structured: a lead sentence, a purpose statement, a usage note, and a brief return summary. Each sentence contributes meaning, though some redundancy exists between the first paragraph and the schema description. It is not overly verbose and front-loads the core purpose.
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 tool's complexity and the presence of an output schema, the description is complete: it explains what the tool does, when to use it, that it is deterministic and read-only, and what the return envelope contains. No major gaps remain for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the sole parameter (candidate_json) with 100% description coverage, including the checks performed. The description reiterates these semantics without adding new parameter-level details. Since the schema does the heavy lifting, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run master-independent safety checks on a candidate recipe.' It specifies the exact checks (poultry temperature and 14 EU FIC allergen groups) and differentiates from siblings by emphasizing 'no dish resolution, no master SOP required' and explicitly contrasting with verify_recipe when no master exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Direct usage guidance is provided: 'Use this when verify_recipe has no matching master for the dish: the safety layer still applies to every recipe.' This clarifies the intended context and distinguishes it from the alternative verify_recipe. The phrase 'Works for ANY recipe' also sets boundary conditions.
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.
ParametersJSON Schema
| 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. | |
| master_json | No | 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 | 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: 'json' (default — includes the full fixed_recipe object) or 'text' (human-readable report). | json |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by detailing the deterministic process (verify, apply corrections, re-verify), listing the types of corrections applied, and explicitly disclosing what is NOT auto-applied (e.g., adding phases, rewriting instructions, allergen fixes). It also explains the response includes verdict before/after, which is valuable behavioral context. No contradiction with annotations (readOnlyHint=false, idempotentHint=true).
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 well-structured and front-loaded with the primary purpose, but it contains redundancy: the caveat about structural changes and patches_skipped is repeated in the final note. This slight repetition prevents a perfect score, though each sentence otherwise earns its place.
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?
For a tool of this complexity, the description is highly complete: it explains the repair process, limitations, return semantics (verdict before/after, patches_skipped), and important caveats. With an output schema and annotations present, the description covers all necessary behavioral and contextual aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are fully described in the schema (100% coverage), so the description does not need to add parameter-level detail. The description adds minimal parameter-specific information but the schema already provides accurate descriptions, including aliases and optionality. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Deterministically repair a candidate recipe against a Guardian master.' It distinguishes itself from siblings like verify_recipe by focusing on repair and applying machine-actionable corrections. The scope is explicit and unambiguous.
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 provides clear context on when to use the tool (to repair a candidate recipe) and explicitly warns about limitations (structural changes and allergen findings are not auto-fixed; verdict_after may still be FAILED). It does not name alternatives directly, but the context and caveats guide appropriate use effectively.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, but the description adds rich behavioral context: no LLM in the hot path, transparent content per ADR-009/010, no score, and structured UNKNOWN_DISH error. This goes well beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, usage, transparency guarantees, return content, and error handling. Structured with line breaks for readability; appropriately sized for a tool with this complexity.
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?
Provides complete context: when to use, what it returns, what it doesn't return (score), and error behavior. Combined with annotations and output schema, the agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters. The description adds some behavior (unknown dish error) but does not materially enhance parameter semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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' with a specific verb and resource. It distinguishes the tool from siblings by positioning it as the reference lookup step before verify_recipe, contrasting with verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the compare-then-verify agentic loop, directing the agent to fetch the master, diff, then call verify_recipe. It also clarifies that this is not for scoring (no verdict per ADR-013), preventing misuse.
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.
This is a browse/discovery step, not the verification itself — after picking a dish, call verify_recipe(dish_name=, candidate_json=) 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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, so no side-effect warning is needed. The description adds useful behavioral context beyond annotations by describing the return payload (schema_version, dishes list, next_step hint) and framing the tool as a discovery step rather than the verification action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: a one-line summary, a concise usage directive with named alternatives, and a compact returns overview. Every sentence adds value, and the most important routing guidance is front-loaded.
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?
For a simple optional-parameter listing tool with a rich output schema and read-only/idempotent annotations, the description is complete. It explains when to use it, what it returns at a high level, and how to proceed to verification, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already documents cuisine_filter clearly, including its default, case-insensitive exact-match behavior, valid values, and how to return all dishes. The description adds no extra parameter-level meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'List all available master dishes with rich metadata.' It clearly distinguishes itself from verification tools by stating it is 'a browse/discovery step, not the verification itself' and explicitly names verify_recipe and fix_recipe as the follow-up tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: use this to browse or discover dishes before verification, then call verify_recipe or fix_recipe afterward. This directly tells the agent when to use this tool and what to use instead for the actual verification step, reducing ambiguity against siblings.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that verification combines existing allergen logic with a curated YAML map, and promises a structured verdict with offending ingredients and a short justification, adding strong behavioral specificity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences lead with the core action, then add implementation and output details; no filler.
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?
For a read-only verification tool with annotations and an output schema, the description covers purpose, mechanism, and result shape. It lacks only explicit sibling differentiation, but that is already captured by the tool's naming and usage guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. The description itself does not elaborate on claim, candidate_json, or response_format; those are already described in the input schema, and the tool description adds no param-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource—'Verify that a recipe satisfies a dietary claim'—and enumerates claim types (vegan, halal, gluten-free), clearly distinguishing it from sibling check_allergens by focusing on dietary labels rather than allergen presence.
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?
It gives clear context: this tool verifies dietary claims and reuses allergen-detection logic, implying a relationship to check_allergens. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
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 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.
ParametersJSON Schema
| 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. | |
| master_json | No | 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 | 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: 'json' (default — machine-actionable verdict, findings, and patches) or 'text' (human-readable report). | json |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses substantial behavioral detail: verdict is strictly PASSED or FAILED with policy thresholds (any CRITICAL or >5 WARNINGs fails), there is no score, issue is machine-readable and must not be shown to users, and both json/text formats are transparent. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused paragraphs with bold labels, front-loaded with a clear purpose statement. Every sentence carries policy, field-audience, or format information; there is no filler or redundancy.
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?
Coupled with the rich schema and annotations, the description fully prepares an agent: it explains verdict policy, field audience, response formats, and transparency guarantees. Since an output schema exists, not detailing every return field in the description is acceptable.
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. The description adds meaningful context beyond the schema's one-line parameter descriptions by explaining response_format behavior ('structured JSON by default... response_format="text" renders a human-readable report'), verdict/findings semantics, and the candidate_json verification dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Verify') and resource ('candidate recipe against a Guardian master recipe'), and then enumerates the verification dimensions (technique, temperature, timing, cooking medium, required ingredients). This clearly distinguishes it from narrower sibling tools like check_allergens, check_safety, and verify_dietary_claim.
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?
It clearly frames when to use this tool—verifying a candidate recipe against a master—and explains when to include original_prompt and how response_format changes output. However, it does not explicitly name alternative tools or state when NOT to use this tool (e.g., for allergen-only checks), so it stops short of full usage exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
check_allergens4 fields changed- added
Input schema / properties / operator_idAdded value: +{ + "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'." +} - changed
Input schema / properties / response_format / defaultPrevious value: -"text"New value: +"json" - changed
Input schema / properties / response_format / descriptionPrevious value: -"Response format: 'text' (default) or 'json'. Use 'json' for machine-actionable output."New value: +"Response format: 'json' (default) for the machine-actionable payload, or 'text' for a human-readable report." - added
Input schema / properties / session_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional session identifier so repeated checks are stitched into one trajectory." +}
3 tool updates
- Added
check_safety - Changed
fix_recipe3 fields changed- added
Input schema / properties / master_jsonAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "additionalProperties": true, + "type": "object" + }, + { + "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." +} - changed
Input schema / properties / response_format / defaultPrevious value: -"text"New value: +"json" - changed
Input schema / properties / response_format / descriptionPrevious value: -"Response format: 'text' (default) or 'json'. Use 'json' to receive the full fixed_recipe object."New value: +"Response format: 'json' (default — includes the full fixed_recipe object) or 'text' (human-readable report)."
- Changed
verify_recipe3 fields changed- added
Input schema / properties / master_jsonAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "additionalProperties": true, + "type": "object" + }, + { + "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." +} - changed
Input schema / properties / response_format / defaultPrevious value: -"text"New value: +"json" - changed
Input schema / properties / response_format / descriptionPrevious value: -"Response format: 'text' (default) or 'json'. Use 'json' for machine-actionable patches."New value: +"Response format: 'json' (default — machine-actionable verdict, findings, and patches) or 'text' (human-readable report)."
4 tool updates
- Added
check_allergens - Added
get_master - Added
verify_dietary_claim - Changed
verify_recipe1 field changed- added
Input schema / properties / operator_idAdded value: +{ + "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'." +}
1 tool update
- Added
fix_recipe
1 tool update
- Changed
verify_recipe1 field changed- changed
Input schema / properties / original_prompt / descriptionPrevious value: -"REQUIRED for useful results. Include the user's original cooking request for personalized feedback. 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 can ONLY return generic, vague error labels — the response will be missing ingredient names, technique details, and actionable corrections. WITH this parameter: Guardian activates Guided Oracle Mode and returns specific, personalised corrections matched to dietary needs, flavour preferences, and technique choices. Always include it — even a short prompt like 'chicken curry recipe' dramatically improves results."New value: +"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."
4 tool updates
- Removed
verify_allergen_label - Removed
verify_dietary_claim - Removed
verify_recipe_text - Removed
verify_recipe_url
5 tool updates
- Changed
list_dishes1 field changed- changed
Input schema / properties / cuisine_filter / descriptionPrevious value: -"Optional cuisine or region to filter by (e.g., 'french', 'chinese', 'italian', 'thai'). Leave empty to return all available dishes."New value: +"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."
- Added
verify_allergen_label - Added
verify_dietary_claim - Added
verify_recipe_text - Added
verify_recipe_url
1 tool update
- Changed
verify_recipe1 field changed- added
Input schema / properties / session_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional session ID to track an agent's improvement loop across multiple attempts." +}
1 tool update
- Changed
verify_recipe1 field changed- added
Input schema / properties / response_formatAdded value: +{ + "default": "text", + "description": "Response format: 'text' (default) or 'json'. Use 'json' for machine-actionable patches.", + "type": "string" +}
6 tool updates
- Removed
check_allergens - Removed
check_safety - Removed
get_technique_hints - Changed
list_dishes1 field changed- added
Input schema / properties / cuisine_filterAdded value: +{ + "default": "", + "description": "Optional cuisine or region to filter by (e.g., 'french', 'chinese', 'italian', 'thai'). Leave empty to return all available dishes.", + "type": "string" +}
- Removed
suggest_substitutions - Changed
verify_recipe1 field changed- changed
Input schema / properties / original_prompt / descriptionPrevious value: -"The user's original cooking request. Copy the user's exact message — do not paraphrase. When provided, activates Intent Spotlighting — matching findings to the user's specific dietary needs and preferences for personalised corrections."New value: +"REQUIRED for useful results. Include the user's original cooking request for personalized feedback. 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 can ONLY return generic, vague error labels — the response will be missing ingredient names, technique details, and actionable corrections. WITH this parameter: Guardian activates Guided Oracle Mode and returns specific, personalised corrections matched to dietary needs, flavour preferences, and technique choices. Always include it — even a short prompt like 'chicken curry recipe' dramatically improves results."
4 tool updates
- Added
check_allergens - Added
check_safety - Added
get_technique_hints - Added
suggest_substitutions
4 tool updates
- Removed
check_safety - Removed
get_technique_hints - Removed
guardian:check_allergens - Removed
guardian:suggest_substitutions
8 tool updates
- Added
check_safety - Added
get_technique_hints - Removed
guardian:check_safety - Removed
guardian:get_technique_hints - Removed
guardian:list_dishes - Removed
guardian:verify_recipe - Added
list_dishes - Added
verify_recipe
8 tool updates
- Added
guardian:check_allergens - Added
guardian:check_safety - Added
guardian:get_technique_hints - Added
guardian:list_dishes - Added
guardian:suggest_substitutions - Added
guardian:verify_recipe - Removed
list_dishes - Removed
verify_recipe
1 tool update
- Changed
verify_recipe1 field changed- changed
Input schema / properties / dish / descriptionPrevious value: -"Name of the dish to verify against (e.g. 'carbonara', 'rendang', 'roast-chicken', 'confit', 'cheesecake', 'kung-pao', 'fried-chicken', 'brisket', 'wellington', 'souffle')."New value: +"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."
1 tool update
- Changed
verify_recipe3 fields changed- added
Input schema / properties / candidate_json / anyOfAdded value: +[ + { + "type": "string" + }, + { + "additionalProperties": true, + "type": "object" + } +] - changed
Input schema / properties / candidate_json / descriptionPrevious value: -"The full candidate recipe as a JSON string. 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>\"}]}"New value: +"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>\"}]}" - removed
Input schema / properties / candidate_json / typeRemoved value: -"string"
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Deterministic fact verification for AI agents — checksums & curated data, not guesses.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Deterministic claim verification with receipts across ~60 domains. No model in the loop.
AI reasoning checks any document against known international standards before your agent acts on it.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables traceable requirement discovery, technical alignment, and ISO-aligned process checking through deterministic MCP tools and resources, without requiring an embedded LLM.1-
- AlicenseAqualityAmaintenanceEnables AI agents to execute multi-step Standard Operating Procedures step by step, with enforcement of completion at each step, making LLM behavior predictable and auditable.53Apache 2.0
- AlicenseNot gradedqualityBmaintenanceDeterministic AI code review with audit records, providing stack-specific rulesets and governance for coding agents.1MIT
Try in Browser
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.