Gaurmon

Change the meals behind the grocery list

update_meals

Destructive

Add, remove, replace or edit the meals behind the user's grocery list; their ingredients go on and off the list to match, in one transaction. Send a whole plan at once with add (at most 21 meals, 40 ingredients each, amounts in any unit). Shared ingredients are combined where units allow. Removing a meal lowers what's needed of shared items and removes items no other meal needs, but never items added by hand; ticked items stay, marked noLongerNeeded. replace swaps a meal for another in one step. Returns the list like get_list plus change (items added and removed, estimate before and after) and undo: the update_meals arguments that reverse it.

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_meals"
  }
}

Input Schema

Name	Required	Description
`add`	No
`near`	No	Where to price the list. Remembered for next time; omit to use the last place.
`remove`	No
`update`	No
`replace`	No
`radiusKm`	No	Search radius in km around `near` (default 5).
`maxStores`	No	Shop at most this many stores (remembered; null clears it). The list is split across the set that prices the most items for the least.
`preferBanners`	No	Only these banners, e.g. ["no-frills", "food-basics"] (remembered; null clears it).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the destructive/not-idempotent annotations: atomicity (one transaction), unit-aware combining of shared ingredients, removal behavior that lowers shared amounts, never deletes hand-added items, keeps ticked items marked noLongerNeeded, and returns an `undo` argument set. This is exactly the pre-mutation context an agent needs for a destructive tool.

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 the core action, then behavior, then return shape; nearly every clause carries information. Slight density and a mild redundancy between 'in one transaction' and 'in one step' keep it below top marks.

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 an 8-parameter destructive tool with no output schema, it explains the return value (get_list shape plus `change` and `undo`) and the main side effects. What's missing is how the location/store parameters interact with the call and any failure modes, but an agent could invoke this correctly.

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?

Adds some meaning (amounts in any unit, shared ingredients combined where units allow, what `remove` does to shared items), but the 21-meal/40-ingredient limits simply restate schema maxItems. The pricing parameters near, radiusKm, maxStores and preferBanners get no treatment in the description, and with 50% schema description coverage the gap is only partly bridged.

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 set (add/remove/replace/edit) and resource (the meals behind the grocery list), and explicitly contrasts meals with the list items their ingredients drive. That contrast is what separates it from the sibling update_list, which operates on list entries, without needing the sibling named.

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?

Gives clear usage context: send the whole plan at once with `add`, and use `replace` to swap a meal in one step. It does not name update_list as the alternative for item-level edits, so the when-not guidance is implied rather than stated.

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

All Gaurmon 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?