WebDiet

webdiet_prescription_write_create

Create, save or publish meal plan prescriptions in WebDiet. Actions: create (new prescription for patient), save (meals/foods JSON to existing prescription), publish (release prescription to patient — makes it visible on the patient portal/app). IMPORTANT: After creating and saving foods, you MUST call publish to make the prescription visible to the patient.

═══ MÉTODO DE PRESCRIÇÃO — escolha no create ═══ WebDiet tem 3 métodos:

• "Convencional" (UI: "Por alimentos", URL: metodoPlanning.php) — DEFAULT e RECOMENDADO. Alimento-por-alimento. Para cálculo de macros automático (proteínas/lipídios/carboidratos/calorias) na tabela "Alimentos prescritos" detalhada, cada alimento DEVE incluir o campo "id" com o WebDiet food-DB ID numérico. Sem id, o alimento AINDA é salvo no método Convencional e aparece no card expandido da refeição com nome + medida caseira, mas sem macros. NÃO vai para a seção qualitativa — o save retorna um warning explicando.

• "Equivalentes" (UI: "Por equivalentes", URL: metodoWebdiet.php) — avançado. Prescrição por grupos de equivalentes. Requer IDs do banco.

• "Qualitativo" (UI: "Qualitativa", URL: metodoQualitativo.php) — texto livre por refeição. A página do Qualitativo usa estrutura de dados diferente (refs com objetos cardapio) que este adapter ainda não gera corretamente via save. Para prescrições qualitativas, recomendado: criar via UI ou usar metodo="Convencional" sem food IDs (os alimentos aparecem como texto na refeição sem macros, efeito semelhante).

═══ prescricao_json (para o save) ═══ JSON array de refeições. Cada refeição: {nome, horario, alimentos:[...]}. Cada alimento: {nome, quantidade, medida_caseira, peso_gramas, id?}.

AUTO-RESOLVE: se "id" não for enviado, o adapter procura automaticamente o melhor match no banco WebDiet (mesmo catálogo do webdiet_food_search) pelo campo "nome" e preenche o id antes de salvar — com isso os macros são calculados mesmo sem pré-chamar webdiet_food_search. O save retorna auto_resolved_foods {resolved, not_found, unresolved[]} indicando quais nomes não tiveram correspondência. Para controle fino (variante específica do banco, gramagem da medida caseira etc.), ainda é recomendado chamar webdiet_food_search e enviar o "id" explicitamente.

Para evitar duplicação na UI ("2 2 fatias (50g)"), use quantidade numérica em "quantidade" e medida_caseira SEM repetir esse número e SEM sufixo "(Xg)" — ex.: quantidade="2", medida_caseira="fatias", peso_gramas="50". O MCP também normaliza automaticamente se você enviar texto completo.

Exemplo sem ids (o adapter resolve automaticamente; nomes pouco específicos podem não encontrar match): [{"nome":"Café da Manhã","horario":"07:00","alimentos":[{"nome":"Pão integral","quantidade":"2","medida_caseira":"fatias","peso_gramas":"60"}]}]

Exemplo com ids (pula o auto-resolve — ideal quando você já escolheu a variante exata): [{"nome":"Almoço","horario":"12:00","alimentos":[{"id":"9153","nome":"Arroz branco cozido","quantidade":"4","medida_caseira":"4 colheres de sopa (100g)","peso_gramas":"100"},{"id":"9168","nome":"Feijão carioca cozido","quantidade":"2","medida_caseira":"2 colheres (50g)","peso_gramas":"50"}]}]

O save retorna {ok, metodo, warnings[], raw, auto_resolved_foods}. warnings avisa sobre alimentos sem id e alimentos não encontrados no banco.

[Flattened action: create]

Bulk support: accepts patient_ids, prescription_ids for batched execution.

Input Schema

TableJSON Schema

Name	Required	Default
`nome`	No	Prescrição Alimentar
`metodo`	No	Convencional
`account`	No
`patient_id`	Yes
`patient_ids`	No
`prescricao_json`	No
`prescription_id`	No
`prescription_ids`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedJun 10, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool writes but is not destructive. The description expands on this by describing the auto-resolve behavior, warning responses, and the exact output of save. No contradiction with annotations. It fully discloses side effects (e.g., foods without id appear without macros).

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 quite long but well structured with clear sections (actions, methods, auto-resolve, examples). Every part earns its place given the complexity. However, some redundancy exists (e.g., repeating the três métodos), and the length could be trimmed slightly without losing clarity.

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?

Despite no output schema, the description details return values for save (ok, metodo, warnings, raw, auto_resolved_foods) and explains the publish action's effect. It covers all 8 parameters, three methods, bulk support, and edge cases (foods without id, auto-resolve warnings). No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions), but the description compensates thoroughly. It explains prescricao_json format with examples, auto-resolve logic, how to avoid duplication in UI, and the meaning of each parameter (nome, metodo, patient_id, etc.). It also covers bulk parameters. The examples are concrete and add significant value.

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 creates, saves, or publishes meal plan prescriptions. It distinguishes three distinct actions (create, save, publish) and lists them upfront. Sibling tools like webdiet_prescription_write_save and webdiet_prescription_write_publish exist, but this tool bundles them with an explanation of when each action applies, making its purpose distinct.

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 provides explicit when-to-use guidance: it details the three methods (Convencional, Equivalentes, Qualitativo) with recommendations, explains the necessity of calling publish, and advises against using Qualitativo via this tool. It also covers bulk support with patient_ids and prescription_ids. Sibling differentiation is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All WebDiet tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0

Disambiguation3/5

Tools are split by action (e.g., separate list, get, write tools for each resource), which makes boundaries somewhat clear, but the sheer number of similar tools (62 total) and repeated descriptions create confusion. An agent must carefully read each tool to pick the correct one, especially when multiple write tools exist for the same resource.

Naming Consistency2/5

Naming conventions are inconsistent. Some tools use `webdiet_<resource>_write_<action>`, others use `webdiet_<resource>_<action>` (e.g., `webdiet_calculo_energetico_write_create` vs. `webdiet_create_antropometria`). There are also tools like `webdiet_food_search` that break the pattern. This makes it hard to predict tool names.

Tool Count2/5

62 tools is excessive for a nutritionist platform. Many action variants (list, get, create, save, publish, delete, etc.) are split into separate tools rather than parameterized within a single tool. This bloats the tool list and could be consolidated to ~20-30 tools without losing functionality.

Completeness4/5

The server covers a very wide range of features: patient management, anamnesis, anthropometry, energy calculations, prescriptions (with multiple methods), financials, pre-consultation questionnaires, orientations, food search, file upload, and more. Minor gaps exist (e.g., no explicit tool for meal reactions), but overall the surface is comprehensive for its domain.

webdiet_prescription_write_create

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources