Splot

Change meal

update_meal

Destructive

Change a saved meal; only what you pass changes. Mark a planned meal as eaten with state logged (and eatenAt if the time differs) rather than creating it again; move, rename or annotate a meal the same way. A field left out keeps its value, and null clears name or notes. Items change one at a time by the item ids the meal returned: items.change sets a portion, items.remove drops items, and items.add adds foods as in create_meal; to swap a food, remove it and add the other. Ask one short question first if a food or portion is unclear. Pass photos the person attached as photos to add them; images replaces the saved photos, and a saved photo left out is deleted. Confirm the change only after success.

Input Schema

Name	Required	Description
`id`	Yes	The id of the meal to change, as list_meals or create_meal returned it
`name`	No	A new name for the meal; null clears it
`items`	No	Changes to the meal's items, by the item ids the meal returned
`notes`	No	New notes for the meal; null clears them
`state`	No	logged for food eaten; planned only for a plan the person asked to save
`images`	No	Photos already saved on this record to keep, or public https image links. New photos from the conversation go in photos, never here.
`photos`	No	Photos the person attached in this conversation to keep with this record: pass the attachments themselves, never file paths
`eatenAt`	No	When it was eaten, or for a plan when it will be, with its UTC offset
`timezone`	No	The IANA timezone where the meal is eaten, such as America/New_York

Output Schema

Name	Required	Description	Default
`id`	Yes
`day`	Yes
`name`	Yes
`items`	Yes
`notes`	Yes
`state`	Yes
`images`	Yes
`eatenAt`	Yes
`category`	Yes
`timezone`	Yes
`nutrition`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 19, 2026
- changedInput schema / properties / items / properties / add / 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 / properties / add / 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 / properties / add / 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 / properties / add / 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 / properties / add / 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 / properties / add / 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"
+}
```
First observedOct 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, but the description adds the concrete blast radius the annotations can't: "images replaces the saved photos, and a saved photo left out is deleted" and items.remove drops items. It also discloses partial-update semantics (omitted fields keep their value; null clears name/notes) and the success-confirmation rule. Permissions, failure modes and idempotency on stale item ids are still unstated, keeping it below 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?

One dense paragraph, but the highest-value rule (only what you pass changes) is front-loaded and each subsequent sentence covers a distinct behavior. It is proportionate to a 9-parameter, deeply nested schema, though it could be easier to scan if the item add/change/remove and photo rules were separated rather than run together.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile; the description fills in the mutation semantics, destructive photo behavior and workflow rules an agent needs. The remaining gap is edge behavior (invalid or stale item ids, partial failure across items.add/change/remove), which is not addressed here or in the schema.

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 description coverage is 100%, so the baseline is 3 and the nested shapes (newFood, images vs photos, unit conversions) are already documented. The description still adds routing value the schema lacks: items.change sets a portion, items.remove drops, items.add behaves as in create_meal, and notably a food swap is done as remove-plus-add rather than a single mutation. It also disambiguates photos (new attachments) from images (saved photos to keep).

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?

Opens with a specific verb and resource ("Change a saved meal") and immediately scopes the semantics ("only what you pass changes"). It differentiates itself from create_meal by telling the agent to mark a planned meal as eaten via state logged "rather than creating it again," though it never names the sibling tools an agent might otherwise pick (e.g. get_meal, delete_meal) as alternatives.

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?

Strong operational guidance: mark planned meals as eaten with state logged rather than re-creating, move/rename/annotate the same way, swap a food by removing and adding, ask one short question first if a food or portion is unclear, and confirm only after success. It stops short of an explicit when-not-to-use this tool section, but the create_meal contrast covers the main routing decision.

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

All Splot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?