Skip to main content
Glama

webdiet_prescription_write_publish

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

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.6/5.0
Behavior4/5

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

The description adds significant behavioral context beyond annotations, such as the requirement to call publish for patient visibility, auto-resolve behavior, and warnings about missing IDs. It does not contradict annotations and provides useful details about side effects and return warnings.

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 comprehensive but verbose, containing extensive technical details and examples. It is front-loaded with the core purpose but could be more concise. The structure is reasonable with sections, but some sentences are repetitive.

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?

Given the tool's complexity (8 params, 3 actions, no output schema), the description covers most aspects: actions, methods, JSON format, auto-resolve, and return structures for save. It lacks full parameter descriptions and overall return type, but is fairly complete for a complex healthcare tool.

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 0%, so the description must explain all parameters. It provides thorough details for prescricao_json (structure, examples) and metodo (enum options). However, it does not explain patient_id, account, prescription_id, patient_ids, prescription_ids, or nome beyond their names, leaving 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, specifying three distinct actions. However, it does not differentiate from sibling tools like webdiet_prescription_write_create and webdiet_prescription_write_save, which may cause confusion about when to use this combined tool.

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 includes important usage notes (e.g., must call publish after save) and method selection guidelines. However, it lacks explicit guidance on when to use this tool versus its siblings, leaving the agent to infer the appropriate context.

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.