Servidor MCP de Kaimei Labs

• Nome no registrodev.kaimeilabs/guardian-engineverificado no registro MCP

O nome no registro fica sob kaimeilabs.dev. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-26
• Ferramentas7
• O servidor se chamaGuardian Engine
• Versão do servidor1.0.0
• Versão do protocolo2025-06-18

Em 2026-10-26 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 362 ms.

• As ferramentas fazem todos os casos de uso verificados: check agent-written recipes for impossible temperatures and wrong ingredients; apply a house recipe or SOP spec to generated recipes; screen recipes for allergens and dietary claims.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCP87 de 100responde 89 · faz o trabalho 100 · definições 100 · contexto 97 · uso 0 · conexão 100
• O que um agente consegue fazer com ele3 de 3 casos de uso
• Respondeuem 89% dos dias8 de 9 verificações diárias
• Mediana da primeira resposta292 ms
• Espaço no contexto do agente≈ 3.318 tokensas definições de todas as ferramentas (7), que o agente carrega a cada turno
• Definições das ferramentasA · 100 de 100
• Resultados tipados7 de 7 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Todas as ferramentas passam nas seis verificações.

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e números →

• verify_recipe

  Verify a candidate recipe against a Guardian master recipe. Uses deterministic graph-based verification to check technique, temperature, timing, cooking medium, and required ingredients. **Verdict**: `verdict` is strictly PASSED or FAILED…

• fix_recipe

  Deterministically repair a candidate recipe against a Guardian master. Verifies the candidate, applies every machine-actionable correction the symbolic engine produced (missing ingredients, quantities, temperatures, durations, cooking…

• list_dishes

  List all available master dishes with rich metadata. This is a browse/discovery step, not the verification itself — after picking a dish, call verify_recipe(dish_name=<slug>, candidate_json=<your recipe>) to actually check a candidate…

• get_master

  Return the canonical master recipe for a dish (read-only, no LLM). Enables compare-then-verify agentic loops: fetch the master, diff it against the user's recipe, then call verify_recipe — instead of verifying blind. Pure knowledge-base…

• check_safety

  Run master-independent safety checks on a candidate recipe. Works for ANY recipe — no dish resolution, no master SOP required. Checks poultry internal-temperature safety and scans all ingredients for the 14 EU FIC 1169/2011 Annex II…

• check_allergens

  Check ingredients for EU FIC 1169/2011 allergen compliance. Returns a detailed audit trace mapping each ingredient to its EU Annex II allergen group with entry numbers and labels. The safety verdict is deterministic — no LLM involvement…

• verify_dietary_claim

  Verify that a recipe satisfies a dietary claim (vegan, halal, gluten-free, ...). Reuses the existing allergen-detection logic plus a curated forbidden-ingredient map (apps/guardian/knowledge/dietary_claims.yaml). Returns a structured…