LastList

Record items used

consume_items

Destructive

Record that the user USED items from their inventory (e.g. after cooking a meal): 'I made the chili', 'we used the last two eggs', 'I cooked with the chicken'. Each named item is decremented by its amount, or removed entirely when no amount is given or the amount covers what's left. Set restock:true to add anything fully used up back onto the shopping list. This is destructive to inventory — only call it when the user has actually consumed the items, never to guess at what a recipe might have used. If you are inferring the items from a recipe, confirm the list with the user first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "consume_items"
  }
}

Input Schema

Name	Required	Description
`items`	Yes	Inventory item names that were used, e.g. ['eggs', 'butter'].
`amounts`	No	Optional per-item amount used, keyed by the same name as in items (e.g. {"eggs": 2}). Omit an item to consume it entirely.
`restock`	No	When true, any item fully used up is added to the shopping list. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, but the description goes further and explains exactly what destruction means: each item is decremented by its amount, or removed entirely when no amount is given or the amount covers the remainder. It also discloses the secondary side effect of restock:true adding used-up items back to the shopping list — context the annotations cannot convey.

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 verb, resource, and illustrative examples, followed by the destructive warning. Every sentence carries information, though the example list is slightly longer than strictly necessary for an already-clear operation.

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?

With no output schema, three fully documented parameters, and annotations covering the safety profile, the description supplies everything an agent needs: what gets decremented, when items are removed, what restock does, and the guardrail against inferring usage.

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 baseline is 3, but the description adds meaning beyond the schema: it clarifies that omitting an amount consumes the item entirely and that restock:true repopulates the shopping list with fully used items. The restock elaboration is a genuine semantic addition rather than a restatement.

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 and resource — 'Record that the user USED items from their inventory' — with concrete examples ('I made the chili', 'we used the last two eggs'). This clearly separates it from siblings like add_items, have_items, and out_of_item without needing to open any 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?

Gives explicit when-to-use examples, an explicit when-not ('never to guess at what a recipe might have used'), and an alternative workflow ('If you are inferring the items from a recipe, confirm the list with the user first'). Nothing is left to inference.

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

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