Skip to main content
Glama

edit_items

Update existing Listonic grocery list items: tick off purchased items, untick them, rename, or adjust amount/unit—send only changed fields in one batch call.

Instructions

Change items already on a list: tick them off when bought (isChecked: true), untick (false), rename, or change amount/unit. "I bought X" = tick it off, do not delete. Send only the fields to change; omitted or null fields stay as they are; send amount 0 and unit "" to clear the quantity. Get itemIds from get_items. Items can't be moved between lists - add to target list and delete from source. Batch: send all items to change in one call. Returns the updated items in get_items format.

Input Schema

NameRequiredDescriptionDefault
itemsYesItems to edit
listIdYesThe list ID (from get_lists)
listNameYesThe list's name exactly as get_lists shows it. Shown in the permission prompt so the user can confirm the right list; not sent to the API.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does most of it well: partial-update semantics (omitted/null fields unchanged), clearing semantics (amount 0 / unit ""), the batch model, the list-move limitation, and the return shape. It stops short of stating what happens on validation failure or whether a batch is atomic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph, front-loaded with the operations, then the null/clear rules, then the move constraint, batching, and return format. No filler sentences; each clause maps to a decision the agent must make.

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?

Covers the nested items array, the permission-prompt side channel (confirmName/listName not sent to the API), and the return format in lieu of an output schema. Missing only error/partial-failure behavior, which matters for a batched mutation.

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 description coverage is 100%, so the schema already documents listId, itemId, amount, unit, and the confirmName permission-prompt role. The description repeats the null-vs-clear rule and the get_items sourcing rather than adding syntax or format detail beyond the schema.

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 (change) and resource (items already on a list), then enumerates every supported operation: tick/untick, rename, change amount/unit. This clearly separates it from add_items and delete_items without needing to open the schemas.

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?

Explicitly resolves the most likely confusion ('I bought X' = tick it off, do not delete), names get_items as the source of itemIds, states the no-move constraint with the add/delete workaround, and directs batching into one call. When-to-use and when-not-to-use are both covered.

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