Skip to main content
Glama

webdiet_prescription_write_save

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: save]

Bulk support: accepts patient_ids, prescription_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nomeNoPrescrição Alimentar
metodoNoConvencional
accountNo
patient_idYes
patient_idsNo
prescricao_jsonNo
prescription_idNo
prescription_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations are minimal but not contradicted. The description explains the write behavior (create/save/publish), auto-resolve mechanics, warnings, and limitations (e.g., qualitative method not yet supported via save). It also notes the need to call publish separately. This provides good transparency beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but overly long, with repetitive explanations and a mix of English and Portuguese. While well-structured with sections, it could be more concise and avoid redundant information, such as repeating the methods details in different sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description covers return values (ok, metodo, warnings, raw, auto_resolved_foods) and the need to call publish. It addresses multiple methods, auto-resolve, and bulk support. However, it does not clarify interaction with sibling tools, leaving some contextual gaps.

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 0%, so the description carries the full burden. It thoroughly explains the 'prescricao_json' parameter with structure, examples, and auto-resolve. The 'metodo' parameter is explained with three enum values. However, the 'account' parameter and bulk parameters like 'patient_ids' and 'prescription_ids' are only briefly mentioned, leaving some gaps.

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 the tool creates, saves, or publishes meal plan prescriptions. It distinguishes between three actions and three methods. However, the presence of sibling tools 'webdiet_prescription_write_create' and 'webdiet_prescription_write_publish' creates ambiguity about the exact scope, especially with a note 'Flattened action: save' that conflicts with the broader actions listed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive guidance on when to use each method, auto-resolve vs explicit IDs, and the necessity of calling publish. However, it does not explicitly differentiate this tool from sibling tools that also handle create and publish, potentially leading to confusion about which tool to use for each action.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.