Skip to main content
Glama

Log or plan meal

create_meal

Save a meal the person asked to log or plan. Find each food with list_foods first and pass a match as food (its library and key); use newFood only when nothing matches, never for a product the catalogue has. If the food or portion is unclear, ask one short question first (for example: chicken or bean burrito, and one or two?), without asking again for what the person already said. Use state logged for food eaten, and planned only for a plan the person asked to save, since suggestions alone are not a request. To log a meal that was planned, use update_meal instead of creating another. For planning, read get_targets first and respect the diet, dislikes and allergies the person mentions. Pass photos the person attached as photos. Say the meal is saved only after this returns its id; after an error or timeout, check list_meals for that day before trying again.

Input Schema

NameRequiredDescriptionDefault
nameNoA name for the meal as a whole, such as Sunday brunch
itemsYesThe foods in the meal, each with its portion
notesNoNotes the person wants kept with the meal
stateNologged for food eaten; planned only for a plan the person asked to savelogged
imagesNoPhotos already saved on this record to keep, or public https image links. New photos from the conversation go in photos, never here.
photosNoPhotos the person attached in this conversation to keep with this record: pass the attachments themselves, never file paths
eatenAtYesWhen it was eaten, or for a plan when it will be, with its UTC offset
timezoneYesThe IANA timezone where the meal is eaten, such as America/New_York

Output Schema

NameRequiredDescriptionDefault
idYes
dayYes
nameYes
itemsYes
notesYes
stateYes
imagesYes
eatenAtYes
categoryYes
timezoneYes
nutritionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / items / items / properties / newFood / properties / data / properties / ingredients / items / properties / newFood / properties / data / properties / ingredients / items / properties / newFood / properties / data / properties / recipe / description
      Previous value: -"For a recipe: its servings, time and steps"New value: +"For a recipe: its servings, time, steps and finished weight"
    • addedInput schema / properties / items / items / properties / newFood / properties / data / properties / ingredients / items / properties / newFood / properties / data / properties / ingredients / items / properties / newFood / properties / data / properties / recipe / properties / weight
      Added value: +{
      +  "description": "The whole recipe's weight once made, in grams, if it was weighed; without it, grams are estimated from the ingredients",
      +  "exclusiveMinimum": 0,
      +  "maximum": 999999999.999,
      +  "type": "number"
      +}
    • changedInput schema / properties / items / items / properties / newFood / properties / data / properties / ingredients / items / properties / newFood / properties / data / properties / recipe / description
      Previous value: -"For a recipe: its servings, time and steps"New value: +"For a recipe: its servings, time, steps and finished weight"
    • addedInput schema / properties / items / items / properties / newFood / properties / data / properties / ingredients / items / properties / newFood / properties / data / properties / recipe / properties / weight
      Added value: +{
      +  "description": "The whole recipe's weight once made, in grams, if it was weighed; without it, grams are estimated from the ingredients",
      +  "exclusiveMinimum": 0,
      +  "maximum": 999999999.999,
      +  "type": "number"
      +}
    • changedInput schema / properties / items / items / properties / newFood / properties / data / properties / recipe / description
      Previous value: -"For a recipe: its servings, time and steps"New value: +"For a recipe: its servings, time, steps and finished weight"
    • addedInput schema / properties / items / items / properties / newFood / properties / data / properties / recipe / properties / weight
      Added value: +{
      +  "description": "The whole recipe's weight once made, in grams, if it was weighed; without it, grams are estimated from the ingredients",
      +  "exclusiveMinimum": 0,
      +  "maximum": 999999999.999,
      +  "type": "number"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only give the generic write/safe profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds real operational behavior: confirm only after an id is returned, and after an error or timeout check list_meals for that day before retrying — an idempotency/retry protocol that is not derivable from the schema. It stops short of covering permissions or duplicate-handling, so 4 rather than 5.

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 purpose and then ordered by workflow (lookup → clarify → state → alternatives → retry), which suits an 8-parameter tool. It is dense but mostly earns its length; the one weak spot is restating the schema's state and photos wording verbatim, which is redundant padding.

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?

An output schema exists, so return values need no explanation. Given the workflow complexity, the description covers prerequisites, alternatives, clarification policy, retry/verification, and photo handling — enough for an agent to call this correctly without reading sibling definitions.

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. The description still adds selection meaning for the food vs newFood decision and the logged-vs-planned distinction, though the state wording largely duplicates the schema's own state description. The photos-vs-images guidance also repeats the schema text.

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?

Opens with a specific verb and resource ("Save a meal") plus the scope ("the person asked to log or plan"), which immediately separates it from get_meal and list_meals. It also names update_meal as the sibling to use for an already-planned meal, so an agent can route without opening either schema.

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?

Explicit routing rules: look up with list_foods and pass food (library+key), use newFood only when nothing matches, use update_meal instead of re-creating a planned meal, read get_targets before planning. It also states when-not (never newFood for a product the catalogue has; suggestions alone are not a request to plan).

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