Splot

Save food or recipe

save_food

Destructive

Save a food or recipe to My foods, or with id update one of the person's foods. Search list_foods first and save a new food only when nothing matches, never for a product the catalogue already has. Each recipe ingredient is a food from list_foods or, only when nothing matches, a newFood, with a portion; the server adds up the nutrition. When changing a shared or saved food, pass copyFrom so its origin is kept: a product change goes to review and does not change the shared catalogue directly. Meals and recipes keep the version they were saved with. Pass photos the person attached as photos.

Input Schema

Name	Required	Description
`id`	No	To update one of the person's own foods: its key from list_foods with library mine. Leave out to save a new food.
`data`	Yes	What the food is: its base unit, nutrition and measures, and for a recipe its ingredients and steps
`name`	Yes	The food's name, without its brand
`brand`	No	The brand, for a packaged or restaurant food
`photos`	No	Photos the person attached in this conversation to keep with this record: pass the attachments themselves, never file paths
`barcode`	No	The EAN or UPC barcode digits from the package
`copyFrom`	No	The food this one was changed from, so its provenance is kept and a product correction can be proposed.

Output Schema

Name	Required	Description	Default
`key`	Yes
`data`	Yes
`name`	Yes
`brand`	Yes
`barcode`	Yes
`library`	Yes
`version`	Yes
`sourceKey`	No
`sourceLibrary`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 19, 2026

changedInput schema / 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 / 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 / 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"
```

added

Input schema / 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 / 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 / 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.3/5.0

Behavior4/5

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

With readOnlyHint=false and destructiveHint=true already declared, the description adds meaningful traits annotations cannot express: the server aggregates recipe nutrition, a product change 'goes to review and does not change the shared catalogue directly', and saved meals/recipes retain their pinned version. It stops short of describing failure modes or permission requirements, but the added behavioral context is substantial.

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?

The core purpose is front-loaded in the first sentence, and each subsequent sentence addresses a distinct concern (search-first, recipe ingredients, copyFrom/review, versioning, photos). It is information-dense and largely earns its length, though the version sentence mentioning 'meals' is slightly tangential for a food tool.

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 a deeply nested 7-parameter tool with an output schema (so returns need no explanation), the description covers the important flows an agent needs: search-before-save, update via id, recipe construction with portions, copyFrom provenance, and photo attachment. Nothing essential to calling it correctly is missing.

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 a baseline of 3 applies, but the description adds real semantics beyond the schema: copyFrom is required when changing a shared/saved food to preserve origin, recipe ingredients are either an existing list_foods food or a newFood with a portion, and photos are passed via 'photos' (not 'images'). These clarify cross-parameter relationships the flat schema does not encode.

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 opens with a specific verb and resource ('Save a food or recipe to My foods') and explicitly covers the update path ('with id update one of the person's foods'), so the create-vs-update duality is clear. It does not fully disambiguate against the sibling create_meal/update_meal for the recipe case, which is the one place an agent might hesitate.

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?

It gives explicit when/when-not rules: 'Search list_foods first and save a new food only when nothing matches, never for a product the catalogue already has.' It also names list_foods as the prerequisite lookup and states the copyFrom condition, so the agent knows exactly which tool to call first and when not to save.

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?