Agent Chef

Update ingredients on hand

update_ingredients

Destructive

Manage pantry stock: add staples, add leftovers with skip days so they drop off, mark staples out to put them back on shopping lists, or remove items.

Instructions

Keep the pantry: add staples the household always has (omit days), add leftovers that should be skipped for a while and then drop off (days, 7 is typical), mark staples out when they run low so they go back on the shopping list, or remove items. Adding a staple that was out puts it back in stock. Don't add a week's groceries: they get cooked that week.

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": "update_ingredients"
  }
}

Input Schema

Name	Required	Description
`add`	No
`out`	No	Staples the household ran out of; they return to stock when an order includes them
`remove`	No	Names to remove
`replace_all`	No

Output Schema

Name	Required	Description	Default
`items`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.1.1Oct 3, 2026

addedInput schema / properties / add / items / properties / days

Added value: +{
+  "description": "Leftover: skip it on shopping lists for this many days, then drop it. Omit for a staple.",
+  "maximum": 60,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / out

Added value: +{
+  "description": "Staples the household ran out of; they return to stock when an order includes them",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / remove / description

Previous value: -"Names to remove (used up)"New value: +"Names to remove"

addedOutput schema / properties / items / items / properties / expires_at

Added value: +{
+  "description": "Leftover: skipped until this time, then dropped",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / items / items / properties / out

Added value: +{
+  "description": "A staple the household ran out of; it is on the shopping list until an order restocks it",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / items / items / properties / staple

Added value: +{
+  "description": "Always on hand; skipped on every shopping list unless out",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

First observedv0.1.0Sep 7, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and openWorldHint=false, so safety is partially covered. The description adds real behavioral model beyond that: leftovers decay after N days, 'out' staples return to stock when an order includes them, and re-adding an out staple restocks it. However, it never mentions replace_all, the most destructive operation, and gives no warning about what remove permanently deletes.

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?

Four modes are packed into a compact set of clauses front-loaded by the 'Keep the pantry' framing, with the exclusion saved for the end where it acts as a caution. The em-dash chain and colloquial framing are slightly dense but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 not be explained, and the annotations carry the safety profile. Still, for a destructive multi-mode mutation the description omits replace_all semantics and any conflict/precedence rule (e.g. an item appearing in both add and remove), leaving an agent guessing on the riskiest path.

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 coverage is 50%, and the description partially compensates: it clarifies the omit-days-means-staple rule and the '7 is typical' leftover convention, plus the meaning of out. But replace_all has no description in the schema and is entirely absent from the description text, leaving one of four parameters undocumented end to end.

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 names a concrete verb (update/keep) and enumerates the four operating modes (add staples, add leftovers, mark out, remove), which lets an agent understand the tool's scope. It does not name the obvious counterpart get_ingredients, so sibling differentiation relies on the agent's inference rather than explicit routing.

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?

It gives per-mode when-to-use guidance (staples vs leftovers vs out) and even an explicit exclusion: 'Don't add a week's groceries: they get cooked that week.' It stops short of naming alternatives, e.g. that get_ingredients should be consulted first to see current stock.

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