Skip to main content
Glama

joiva_plan_food

Plan a meal the signed-in user intends to eat later ('plan my dinner at 19:00', 'breakfast tomorrow'). Creates a planned entry in Joiva. It does not count towards the day's totals until it is confirmed as eaten. Food matching and nutrient resolution work as for a logged food: the food name in the user's own language, brand/barcode identify branded products.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "food": "<food>",
      "grams": "<grams>"
    },
    "name": "joiva_plan_food"
  }
}

Input Schema

NameRequiredDescriptionDefault
tzNoIANA timezone, default Europe/Berlin
foodYesFood name, e.g. 'Vollkornbrot'
mealNoMeal name in the user's language: 'Frühstück', 'Mittagessen', 'Abendbrot', 'Snack'. Components with the same meal name on the same day are grouped automatically. A day can have several snacks: part-of-day names place a snack without a clock time ('Vormittagssnack' sorts before lunch at 10:00, 'Nachmittagssnack' 15:00, 'Abendsnack' 21:00); snacks at different times stay separate meals.
brandNoManufacturer/brand, e.g. 'Hamfelder'. Keeps products with different label values apart
gramsYes
notizNoShort note on the preparation, e.g. 'selbst geröstet, 10 min 170 °C'.
garungNoHow it was prepared when eaten, exactly one of: roh, gekocht, gedämpft, gebacken, geröstet, gebraten, gegrillt. Not given = as bought (the product's own state is copied); null = clear. Joiva re-derives the values: a measured BLS variant first (e.g. roasted hazelnuts), else documented USDA retention factors; otherwise the entry reports that the preparation is not accounted for.
mealIdNoExplicit grouping id; normally unnecessary, since `meal` groups automatically
barcodeNoEAN/UPC digits. Links the food to Joiva's global product catalog
subTypeNoVariant, e.g. 'zart'
unitCountNoHow many of that unit, e.g. 2 for 'zwei Eier M'. Only stored together with unitLabel.
unitLabelNoHow the amount was meant, e.g. 'Ei M', 'Scheibe', 'EL'. Display only: `grams` stays mandatory and remains the stored amount, so both are given. Labels that match a food's existing `portions` (name and gram weight, as listed in the food catalog) reuse that portion. Not needed when the user gave a weight.
behandlungNoPre-treatments, any of: eingeweicht, gekeimt, fermentiert, geräuchert, gepökelt (e.g. soaked AND roasted nuts = behandlung ['eingeweicht'] + garung 'geröstet'). Not given = as bought; [] = none.
plannedForNoExact ISO 8601 timestamp with offset, e.g. '2026-09-05T09:00:00+02:00'. For a meal with a named time ('dinner at 7'). Default timezone Europe/Berlin.
plannedDateNoYYYY-MM-DD for a meal planned for a day without a specific time ('breakfast tomorrow').
nutrientSourceNoProvenance of nutrientsPer100g: 'label' when read literally off the product's printed per-100g nutrition table, 'user' when the user dictated exact values; absent for estimates.
nutrientsPer100gNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / unitLabel / description
      Previous value: -"How the amount was meant, e.g. 'Ei M', 'Scheibe', 'EL'. Display only: `grams` stays mandatory and remains the stored amount, so both are given. Labels from a food's `portions` (returned by joiva_search_foods and joiva_list_frequent_foods with their gram weight) match existing portions. Not needed when the user gave a weight."New value: +"How the amount was meant, e.g. 'Ei M', 'Scheibe', 'EL'. Display only: `grams` stays mandatory and remains the stored amount, so both are given. Labels that match a food's existing `portions` (name and gram weight, as listed in the food catalog) reuse that portion. Not needed when the user gave a weight."
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds the genuinely useful behavior that planned entries are excluded from daily totals until confirmed, plus how nutrient resolution and food matching work. It does not warn about duplicate creation on repeated calls despite idempotentHint=false, which would have been the natural next disclosure.

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

Conciseness5/5

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

Three sentences, each earning its place: purpose and examples first, then the persistence/accounting caveat, then the input-matching rule. No filler and no repetition of schema content beyond what is needed for orientation.

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?

For a 17-parameter mutation tool with a nested nutrients object, the description covers the intent, the lifecycle (planned vs eaten), and the input-matching model, while the rich schema handles field-level detail. What is missing is post-call information: what the response contains (entry id, resolved nutrients) and how the planned entry is later confirmed or listed.

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 description coverage is 88%, so the schema already carries the parameter semantics and the baseline is 3. The description only restates that `food` is the name in the user's language and that `brand`/`barcode` identify branded products, adding no meaning beyond the existing field descriptions for the other 15 parameters.

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?

States a specific verb and resource ("Plan a meal ... Creates a planned entry in Joiva") with two concrete user-utterance examples, and immediately contrasts it with logged food ("does not count towards the day's totals until it is confirmed as eaten"), which is what separates it from joiva_log_food and joiva_confirm_planned.

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?

The description makes the when-to-use condition explicit via the example utterances ("plan my dinner at 19:00", "breakfast tomorrow") and the planned-vs-eaten distinction. It stops short of naming the sibling tools to use instead (joiva_log_food for already-eaten food, joiva_confirm_planned to promote an entry), so the routing is inferable rather than stated.

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