Skip to main content
Glama

Zovo Meal Planner

Generate meal plan and grocery list

generate_meal_plan
Read-onlyIdempotent

Use this when the user wants a weekly meal plan, a meal planner template filled in, or a grocery list from their meal plan or meal prep. First turn what the user pasted (a plan, recipe, spreadsheet or e-mail) into meals: one entry per day and slot with its name, recipe servings and ingredient lines, one meal per day for lines like "Mon-Fri lunch". Put the original text in plan only when you cannot do that. If you propose the meals, pass them the same way. The tool parses quantities and units, scales servings to the number of people, merges the same ingredient across the week (volume with volume, weight with weight, not volume to weight), groups the list by store section, removes items the user already has, and returns a PDF (week grid plus checklist), CSV and text. Does not give nutrition, calorie or diet advice and does not order groceries.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "generate_meal_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
planNoFallback when you cannot build meals: the week as the user wrote it. Easiest: a list of meals, e.g. [{"day":"Monday","meal":"Dinner","name":"Chicken stir fry","servings":4,"ingredients":["1 lb chicken thighs","2 cups rice","1/2 onion, diced","salt to taste"]}]. Also accepted: a list of days each with "meals", an object keyed by day and meal, or pasted text (markdown with **Monday** or ### Monday headings and "- Dinner: Tacos (1 lb beef, 8 tortillas)" lines, a markdown or spreadsheet table, or a recipe copied from a website).
mealsNoPreferred. The week as structured meals you build from what the user pasted: one entry per meal and day, e.g. [{"day":"Monday","slot":"Dinner","name":"Tacos","servings":4,"ingredients":["1 lb ground beef","8 corn tortillas"]}]. Expand "Mon-Fri" or "Mon & Wed" into one meal per day.
titleNoTitle printed on the PDF, e.g. "Family dinners". Default "Weekly meal plan" or "Grocery list". Longer than 80 characters is shortened.
unitsNoHow to show merged amounts: "us" (cups, tbsp, oz, lb), "metric" (ml, l, g, kg) or "auto" (default: the system most lines use). Volume is never converted to weight.
peopleNoServings to cook for each meal, e.g. 4 or "4 people". Each meal with a recipe yield (servings) is scaled to this number; meals without a yield are used as written. Default: no scaling.
week_ofNoOptional label for the week, e.g. "Nov 2, 2026". Printed as given; longer than 40 characters is shortened.
page_sizeNoPDF paper: "letter" (default) or "a4".
already_haveNoItems already in the kitchen to leave off the list, as a list or comma-separated text, e.g. ["salt", "olive oil", "rice"]. A section name such as "spices" removes that whole section.

Output Schema

NameRequiredDescriptionDefault
daysYes
mealsYes
notesYes
titleYes
unitsYes
peopleYes
sectionsYes
downloadsYes
items_countYes
meals_countYes
unparsed_linesYes
already_have_removedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare this read-only, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds substantial behavior beyond that: quantity/unit parsing, serving scaling to the number of people, ingredient merging rules (volume with volume, weight with weight, never volume to weight), store-section grouping, removal of already-owned items, and three output artifacts. It also names the transformation the model must perform before calling.

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?

Front-loaded with the trigger sentence, then the input-shaping instructions, then behavior, then exclusions — a sensible order with no filler. It is a single dense paragraph with several chained clauses, which makes it slightly harder to scan than a short bulleted form, but every sentence carries information.

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?

For an 8-parameter tool with an output schema, the description covers the input normalization contract, the scaling and merging logic, the output formats and the explicit out-of-scope limits. An agent could invoke it correctly without opening the schema, which is the standard this tool's complexity demands.

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 100%, so the baseline is 3, but the description earns more by giving precedence rules the schema does not: build structured meals first and use the raw plan text 'only when you cannot do that', and expand range lines like 'Mon-Fri lunch' into one meal per day. Those are genuine invocation decisions rather than restated field docs.

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 opening sentence names a concrete verb and deliverable set: a weekly meal plan, a filled-in template, or a grocery list, all derived from the user's meal prep. That is well beyond a restatement of the name. It stops short of 5 because the sibling generate_grocery_list is never mentioned, so the agent has to guess where the boundary lies between a grocery list produced here and one produced by the sibling.

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

Usage Guidelines4/5

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

Explicit triggering conditions are given ('when the user wants a weekly meal plan...') plus hard exclusions: no nutrition, calorie or diet advice, and no grocery ordering. The gap is that no alternative tool is named; with generate_grocery_list as a sibling, the description should say which one wins when the user only wants a list.

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.

Resources