Skip to main content
Glama

Update an item

update_item
Idempotent

Update selected fields of an inventory item, such as name, brand, location, notes, or value, while leaving omitted fields unchanged.

Instructions

Changes some of an item's fields — name, brand, value, category, notes, the box it's in… — after the person has said what to change (or confirmed suggestions from get_item). Fields left out stay as they are; send null to clear one. tags and links replace the whole list (send the old ones you want to keep). For just moving it use move_item; for using some up or restocking use adjust_stock, which logs the change; for a counter reading use record_reading. Returns the updated item.

Input Schema

NameRequiredDescriptionDefault
idYesThe item's id, from search_inventory or list_items
heirNoWho should have it one day
nameNoWhat it is, the way people would look for it: "Cordless drill"
tagsNoTag names; new ones are created. When updating, the full new list
brandNoWho made it
linksNoWeb links: the maker's page, the manual online… When updating, the full new list
modelNoModel name or number, as on its label
notesNoAnything else worth keeping: where the spare key is, quirks, settings
wantedNoOn the want list: not owned yet — left out of totals, the report, stock and search unless asked for
barcodeNoIts UPC/EAN barcode (also learned into the household's barcode book)
favoriteNoStarred, to find quickly in the app
quantityNoHow many there are; to count stock up or down, adjust_stock logs the change
conditionNoWhat shape it's in
usageUnitNoWhat its counter measures, for maintenance by use (a car's miles, a mower's hours)
categoryIdNoA category id from list_categories
disposedOnNoWhen it went, yyyy-mm-dd
locationIdNoWhere it's kept: a location id from list_locations (null: nowhere in particular)
templateIdNoThe item template it's made from (list_categories), whose fields it then has
valueCentsNoWhat one is worth now, in cents — used for the insurance report
descriptionNoA longer description: colour, size, what it's for
dispositionNoNo longer had: sold, given, discarded, lost or stolen (null: still have it). Gone items leave lists and totals
isContainerNoA box, bin or case that holds other items (they set containerItemId to it)
minQuantityNoKeep at least this many: at or below it, it goes on the shopping list
collectionIdNoThe collection it's part of (list_collections)
customFieldsNoValues for its category's or template's extra fields, by their keys (list_categories shows them)
disposalNoteNoWho it went to, or what happened (for a lost or stolen claim)
purchaseDateNoWhen it was bought, yyyy-mm-dd
serialNumberNoIts serial number, for warranty claims and insurance
disposalCentsNoWhat it sold for, in cents
containerItemIdNoThe box it's in: an item id with isContainer; it's then wherever the box is
purchasePriceCentsNoWhat was paid for one, in cents (12999 = $129.99)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed31 schema fields changedv0.1.1
    • addedInput schema / properties / barcode / description
      Added value: +"Its UPC/EAN barcode (also learned into the household's barcode book)"
    • addedInput schema / properties / brand / description
      Added value: +"Who made it"
    • addedInput schema / properties / categoryId / description
      Added value: +"A category id from list_categories"
    • addedInput schema / properties / collectionId / description
      Added value: +"The collection it's part of (list_collections)"
    • addedInput schema / properties / condition / description
      Added value: +"What shape it's in"
    • addedInput schema / properties / containerItemId / description
      Added value: +"The box it's in: an item id with isContainer; it's then wherever the box is"
    • addedInput schema / properties / customFields / description
      Added value: +"Values for its category's or template's extra fields, by their keys (list_categories shows them)"
    • addedInput schema / properties / description / description
      Added value: +"A longer description: colour, size, what it's for"
    • addedInput schema / properties / disposalCents / description
      Added value: +"What it sold for, in cents"
    • addedInput schema / properties / disposalNote / description
      Added value: +"Who it went to, or what happened (for a lost or stolen claim)"
    • addedInput schema / properties / disposedOn / description
      Added value: +"When it went, yyyy-mm-dd"
    • addedInput schema / properties / disposition / description
      Added value: +"No longer had: sold, given, discarded, lost or stolen (null: still have it). Gone items leave lists and totals"
    • addedInput schema / properties / favorite / description
      Added value: +"Starred, to find quickly in the app"
    • addedInput schema / properties / heir / description
      Added value: +"Who should have it one day"
    • addedInput schema / properties / id / description
      Added value: +"The item's id, from search_inventory or list_items"
    • addedInput schema / properties / isContainer / description
      Added value: +"A box, bin or case that holds other items (they set containerItemId to it)"
    • addedInput schema / properties / links / description
      Added value: +"Web links: the maker's page, the manual online… When updating, the full new list"
    • addedInput schema / properties / locationId / description
      Added value: +"Where it's kept: a location id from list_locations (null: nowhere in particular)"
    • addedInput schema / properties / minQuantity / description
      Added value: +"Keep at least this many: at or below it, it goes on the shopping list"
    • addedInput schema / properties / model / description
      Added value: +"Model name or number, as on its label"
    • addedInput schema / properties / name / description
      Added value: +"What it is, the way people would look for it: \"Cordless drill\""
    • addedInput schema / properties / notes / description
      Added value: +"Anything else worth keeping: where the spare key is, quirks, settings"
    • addedInput schema / properties / purchaseDate / description
      Added value: +"When it was bought, yyyy-mm-dd"
    • addedInput schema / properties / purchasePriceCents / description
      Added value: +"What was paid for one, in cents (12999 = $129.99)"
    • addedInput schema / properties / quantity / description
      Added value: +"How many there are; to count stock up or down, adjust_stock logs the change"
    • addedInput schema / properties / serialNumber / description
      Added value: +"Its serial number, for warranty claims and insurance"
    • addedInput schema / properties / tags / description
      Added value: +"Tag names; new ones are created. When updating, the full new list"
    • addedInput schema / properties / templateId / description
      Added value: +"The item template it's made from (list_categories), whose fields it then has"
    • addedInput schema / properties / usageUnit / description
      Added value: +"What its counter measures, for maintenance by use (a car's miles, a mower's hours)"
    • addedInput schema / properties / valueCents / description
      Added value: +"What one is worth now, in cents — used for the insurance report"
    • addedInput schema / properties / wanted / description
      Added value: +"On the want list: not owned yet — left out of totals, the report, stock and search unless asked for"
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, idempotent, closed-world, so the safety bar is partly met. The description still adds the two behaviors that matter most for a partial update: omitted fields are preserved and null clears a field, plus the footgun that tags and links replace the entire list rather than merging. Only the return payload is treated shallowly ("Returns the updated item").

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 the update rules, then the sibling routing, then the return. Every sentence carries a distinct rule. The only waste is the trailing ellipsis in the field list, which signals incompleteness without adding information.

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 a 31-parameter mutation tool this is close to sufficient: the agent knows how updates are applied, how to clear values, which values replace whole lists, when to prefer a sibling, and that it gets the item back. Minor gaps are unaddressed interactions (for example setting disposition alongside quantity or containerItemId side effects), but those are individually documented in the schema.

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 the baseline is 3 and per-field meanings are already documented. The description goes beyond that with cross-field update semantics that no individual property description carries: omit-to-keep, null-to-clear, and full-list replacement for the two collection-valued fields.

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?

Opens with a specific verb and resource ("Changes some of an item's fields") and immediately enumerates the field families so the agent knows the surface area. It also names the counterpart tool get_item as the source of confirmed suggestions, making it distinguishable from siblings without opening a 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?

Explicitly routes three adjacent intents away: move_item for relocation, adjust_stock for count changes because it logs them, and record_reading for counter values. It also states the precondition (the person has said what to change), which is the when-to-use condition rather than just a when-not.

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