Local MCP server for structured traditional-recipe research: it provides onboarding questions, plans the first search, and validates research batches/deliveries without browsing the web or certifying food safety.
onboarding_questions: supplies non-persistent food-profile questions without collecting identity or diagnosing.
plan_research: after profile confirmation and dish disambiguation, plans the host’s first culinary search using dish, country, variant, and preferences.
validate_research: checks a seven-source research batch’s declared sources, queries, tracks, provenance/editorial evidence, and counts; returns issues and limitations.
validate_delivery: checks delivery ingredients, steps, batch/profile consistency, and declared label/cross-contact review without certifying safety.
Enforces schema constraints and may require semantic review; it does not access pages, prove source truth, or call other models.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Receitas Tradicionais Canônicas Vamos configurar minha cozinha: evito frutos do mar e quero porções para duas pessoas"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Peça um prato à sua IA. Ela pesquisa sete receitas em sites do país de origem, compara o preparo e procura os detalhes que fazem diferença na cozinha de casa.
Você recebe ingredientes, passos curtos e sinais para reconhecer o ponto. Pode pedir uma etapa por vez, medidas caseiras ou uma explicação técnica mais detalhada.
Distribuição 1.0.0, instrução v6.1. A pesquisa depende de uma IA com acesso à internet. O projeto organiza e verifica o processo; não promete encontrar todo conhecimento culinário existente.
Related MCP server: yes_chef_mcp
Abra a instrução para sua IA e copie o conteúdo para as instruções do projeto ou para uma nova conversa.
Diga: “Vamos configurar minha cozinha”. A IA pergunta quais alimentos evitar, alergias, intolerâncias, preferências, porções e utensílios. Você pode responder uma pergunta por vez.
Peça, por exemplo: “Quero uma feijoada brasileira. Mostre as diferenças regionais antes de escolhermos”.
Se o mesmo nome indicar pratos diferentes, a IA apresenta os nomes comuns, o país ou região e os ingredientes básicos de cada opção. A escolha é sua.
O perfil vale para a conversa. Guardá-lo em memória ou arquivo depende de sua escolha. Não publique informações pessoais em issues, exemplos ou forks.
Sete receitas-fontes, de sete grupos editoriais distintos, com conteúdo efetivamente lido e evidência de atuação editorial no país. O endereço do site, sozinho, não comprova isso.
Duas frentes: receitas de referência e receitas domésticas ou regionais. O saber de quem cozinha em casa tem lugar na pesquisa, com autoria e procedência.
Ingredientes, preparo, observações e comentários são lidos antes da seleção. Detalhes minoritários não desaparecem por votação.
As sete receitas são comparadas sem juntar, silenciosamente, versões regionais diferentes. Uma adaptação é identificada como adaptação.
Quando faltarem fontes elegíveis ou a qualificação editorial estiver pendente, a IA explica o que faltou. O contrato rejeita a pendência; não inventa a sétima receita.
Perguntas sobre alimentos evitados entram na configuração inicial. Avisos aparecem quando há uma questão concreta, sem repetir ressalvas genéricas a cada resposta.
O padrão deste projeto é preparo sem bebidas alcoólicas. As demais escolhas alimentares são configuráveis; instruções superiores da sua IA continuam aplicáveis.
O servidor local oferece perguntas iniciais, plano de pesquisa, esquemas e validadores. Ele não navega na internet nem chama outros modelos. A IA conectada realiza as buscas e a coordenação dos papéis com suas próprias ferramentas.
A instrução completa acompanha o pacote e é oferecida pelo MCP. Veja a instalação e conexão e os clientes efetivamente testados. Também é possível usar apenas a instrução, sem instalar software.
A pesquisa inicial registra o que funcionou e o que falhou. A primeira rodada não encontrou o detalhe procurado. A exploração de variantes regionais encontrou o uso culinário do ingrediente-alvo, sem inseri-lo nas consultas. Isso não comprova os efeitos fisiológicos atribuídos a ele.
Há um lote real revalidado com sete fontes, o registro histórico da descoberta e testes com casos sintéticos. A revalidação posterior passou no contrato documental com contadores medidos; ela reutiliza fontes conhecidas e não é outra descoberta cega. Nenhum exemplo é certificação de segurança ou receita clínica.
Pode copiar, adaptar e distribuir. Preserve os créditos e cite o repositório original, indicando alterações. Consulte licenças e atribuição, como contribuir e limites da verificação.
Receitas e imagens dos sites consultados continuam sob os direitos de seus respectivos autores. Os exemplos contêm inventários factuais e resumos próprios, com links, sem reproduzir os textos integrais.
Confiança: alta nos contratos e cenários ensaiados; a experiência em outras IAs depende das capacidades do cliente.
Pendências de cobertura: interfaces não ensaiadas, outros pratos e estudos com usuários. Consulte verificação e clientes testados para o alcance das evidências.
Fornece perguntas sem coletar identidade, diagnosticar ou persistir o perfil.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully extends this with privacy guarantees — no identity collection, no diagnosis, no profile persistence — which is real context an agent would not otherwise know. It stops short of describing the output shape, though an output schema exists.
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?
A single front-loaded sentence with no filler, and the exclusion clauses come last as supporting context. It is efficient, though the terseness leaves the domain of the questions unstated rather than merely brief.
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 no parameters and an output schema present, the description needn't explain return values. However, it never conveys the subject matter or volume of questions (the title's food-survey framing appears nowhere in the description), leaving a gap for an agent deciding whether this output fits its task.
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?
The schema has zero parameters and 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics gap exists.
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 verb 'Fornece' plus the resource 'perguntas' gives a rough purpose, but what kind of questions (the food-survey onboarding suggested by the title) is never stated in the description itself. An agent can tell it returns some question set, but not what domain or format those questions take.
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?
There is no statement of when to call this tool, no prerequisites, and no reference to the siblings (plan_research, validate_research, validate_delivery) or any alternative. The only scoping present is negative ('sem coletar identidade'), which describes behavior rather than call conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Após confirmação alimentar e desambiguação, planeja a primeira busca do host.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the "planning only, no live web access" nature is consistent. The description adds the workflow gating condition, but says nothing about what side state is created, what happens if ambiguity_resolved=false, or what the plan looks like — the output schema is left to carry returns.
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?
A single short sentence with the precondition front-loaded, so there is no wasted text. But this is brevity through under-specification rather than economy — nothing is left to trim, yet key contract facts are missing.
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?
The tool has an output schema and read-only annotations, which relieve some burden, but the input contract is a required nested object with five fields and a ten-field Profile. For a workflow-orchestration step in a four-tool pipeline, one sentence of sequencing context is not enough to call it correctly.
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 0% and the only parameter is a deep nested Request with dish, country (ISO-2 pattern), variant, ambiguity_resolved and a full Profile object. The description contributes zero information about any of these fields — not even the meaning of "variant" or how ambiguity_resolved should relate to the precondition it mentions.
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?
"Planeja a primeira busca do host" gives a verb and an object, but "planejar" is abstract — an agent cannot tell whether this produces search queries, a research outline, or a call to the host. It is close to restating the name (plan_research) plus a precondition, and it does not differentiate itself from sibling validate_research beyond ordering.
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 preconditions "após confirmação alimentar e desambiguação" implicitly tell the agent when this tool is valid (after onboarding confirmation and ambiguity resolution). However, no sibling is named, no when-not condition is given, and the relationship to validate_research / validate_delivery in the pipeline is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confere lote, perfil, inventário e revisão declarada, sem certificar segurança alimentar.
| Name | Required | Description | Default |
|---|---|---|---|
| delivery | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| issues | Yes | |
| checked_at | Yes | |
| limitations | Yes | |
| semantic_review_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds one genuinely useful caveat beyond annotations: passing this check does not certify food safety, which prevents over-claiming downstream. It does not disclose what happens on failure (exception vs. issue list) or which rules are enforced, though an output schema exists that may carry results.
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?
A single dense sentence with zero filler, and the checked items are front-loaded ahead of the scope caveat. It is arguably too terse for a deeply nested payload, but nothing in it is wasted.
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 a large nested input schema, an output schema, and read-only annotations, the description supplies only the subject list and one disclaimer. For a validation gate whose entire value is knowing which constraints are enforced, this leaves the agent guessing about acceptance criteria and failure semantics.
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?
Top-level schema description coverage is 0%, but the description partially compensates by naming the four things being checked (batch, profile, ingredients, declared review), which maps onto the key Delivery fields. Beyond that mapping it adds no semantics for the deeply nested Profile, ResearchBatch, or SourceEvidence structures, leaving the agent to read 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?
"Confere lote, perfil, inventário e revisão declarada" gives a specific verb (confere/validates) plus the concrete artifacts it inspects, and the trailing "sem certificar segurança alimentar" bounds the purpose. It is clearly a delivery-payload validator, distinguishable in intent from validate_research, though it never names a sibling explicitly.
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?
Usage is implied rather than stated: the agent can infer this validates a Delivery object, presumably before final output. There is no explicit when-to-use, no ordering guidance relative to validate_research or plan_research, and no statement of what a failing validation means for the workflow. The scope exclusion is the only real guidance offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifica declarações documentais, sem acessar páginas ou provar sua veracidade.
| Name | Required | Description | Default |
|---|---|---|---|
| batch | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| issues | Yes | |
| checked_at | Yes | |
| limitations | Yes | |
| semantic_review_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this by stating the tool does not access pages or prove veracity — useful confirmation that validation is purely over supplied declarations. However, it says nothing about what happens on failure, whether validation is blocking, or what criteria the checks apply, so value beyond annotations is modest.
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?
One short sentence, front-loaded with the verb and with zero filler. It is efficient, though the terseness is partly under-specification rather than disciplined compression.
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 tool whose schema is a deeply nested research batch (sources, queries, tracks, reformulations, provenance evidence), a single sentence leaves the agent without the batch semantics, validation criteria, or placement in a research pipeline. An output schema exists, so return values need not be explained, but the input-side and workflow context are conspicuously missing.
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?
The single `batch` parameter is undocumented at the top level (0% schema description coverage per the signals). The description adds no meaning about what a batch must contain, that it holds up to 100 sources and queries, or how the seven-source expectation from the title relates to it — the agent must infer everything from the nested $defs.
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 pairs a verb ("Verifica") with an object ("declarações documentais"), so the basic action is graspable, but "documentary declarations" is vague — nothing indicates it validates a research batch of sources (the title mentions seven source-recipes, the description does not). It also gives no signal distinguishing it from the sibling validate_delivery or plan_research.
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?
There is no statement of when to call this tool, what preconditions must hold, or which alternative to use instead. The only guidance is negative scope ("sem acessar páginas ou provar sua veracidade"), which hints the tool must be invoked after sources are gathered but never says so explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0validate_delivery4 fields changedInput schema / $defs / EditorialCountryEvidence / properties / verificationAdded value: +{
+ "default": "pending",
+ "description": "Qualificação declarada da relação editorial com o país; exige revisão semântica das evidências.",
+ "enum": [
+ "confirmed",
+ "pending"
+ ],
+ "title": "Verification",
+ "type": "string"
+}Input schema / $defs / SourceEvidence / properties / provenance_origin / descriptionAdded value: +"URL HTTP(S) da publicação original da receita, usada para identificar republicações; não informe descrição em prosa."Input schema / $defs / SourceEvidence / properties / provenance_origin / formatAdded value: +"uri"Input schema / $defs / SourceEvidence / properties / provenance_verificationAdded value: +{
+ "default": "pending",
+ "description": "Qualificação declarada da origem e da independência editorial; exige revisão semântica das evidências.",
+ "enum": [
+ "confirmed",
+ "pending"
+ ],
+ "title": "Provenance Verification",
+ "type": "string"
+}validate_research4 fields changedInput schema / $defs / EditorialCountryEvidence / properties / verificationAdded value: +{
+ "default": "pending",
+ "description": "Qualificação declarada da relação editorial com o país; exige revisão semântica das evidências.",
+ "enum": [
+ "confirmed",
+ "pending"
+ ],
+ "title": "Verification",
+ "type": "string"
+}Input schema / $defs / SourceEvidence / properties / provenance_origin / descriptionAdded value: +"URL HTTP(S) da publicação original da receita, usada para identificar republicações; não informe descrição em prosa."Input schema / $defs / SourceEvidence / properties / provenance_origin / formatAdded value: +"uri"Input schema / $defs / SourceEvidence / properties / provenance_verificationAdded value: +{
+ "default": "pending",
+ "description": "Qualificação declarada da origem e da independência editorial; exige revisão semântica das evidências.",
+ "enum": [
+ "confirmed",
+ "pending"
+ ],
+ "title": "Provenance Verification",
+ "type": "string"
+}v0.1.0onboarding_questionsplan_researchvalidate_deliveryvalidate_researchScored across 4 tools
Tools have distinct purposes: two validation types (research vs delivery), one planning, and one onboarding. The shared 'research' theme in validate_research and plan_research could cause slight confusion, but descriptions clearly delineate their boundaries.
Most tools follow a consistent snake_case verb_noun pattern (validate_research, validate_delivery, plan_research), but onboarding_questions is a noun phrase, a minor deviation from the convention.
With 4 tools, the set is well within the ideal 3–15 range and each tool appears to serve a specific, non-redundant role in the workflow.
The server name suggests a recipe domain, yet there are no tools to retrieve, create, update, or list recipes. The surface focuses only on validation and planning meta-tasks, leaving significant gaps for core recipe operations.
Recipe search, ingredient matching, nutrition filters and a private cookbook for any AI agent.
Scraps Kitchen gives any AI agent a persistent, household-aware kitchen memory. Unlike generic chatbot recall, Scraps maintains structured cooking data: what's in your fridge (with freshness tracking), who you cook for (with allergens, dietary restrictions, and preferences), your recipe collection (with cook notes and per-diner ratings), your shopping list, and your kitchen equipment. 27 tools across 6 domains let agents read kitchen context, suggest meals that respect dietary safety, update the pantry after cooking, and build a history of what works for your household. Every interaction makes the data richer. Cooking history, preference signals, kitchen awareness = better suggestions next time. All tools work via oAuth and a free scraps.kitchen account.
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
Search, save, organize, cook, and share recipes with any AI assistant.
