Skip to main content
Glama

Change a list

edit_list
Destructive

Changes a list that already exists, all of it in one call. list sets the list's own title, display unit, trip dates and trail (only the fields given; an empty string clears a date or the trail). folders renames, reorders, reclassifies or removes folders, named by id or current name; removing one removes its rows. add puts new rows on, into a folder by name (made when missing) or under a group by the parent row's id. update changes rows by the ids get_list gives: any field, null clearing one that can be cleared; a new folder, place or group; a catalog_id to link or relink the row where it sits, null to unlink. remove takes rows off by id, a group's nested rows with it. The parts apply in that order as one change, and nothing is applied unless every part is valid: a row or folder named that isn't there fails the whole call. A name or weight changed on a catalog-linked row is kept as the owner's own. Takes the list's edit link, or its share code under a signed-in account that has filed it.

Input Schema

NameRequiredDescriptionDefault
addNoNew rows. Each may name its folder, or the group to join.
listNoThe list's own fields. Only the fields given change.
againNoA call with rows to add that is identical to one made in the last ten minutes is taken as a retry and does nothing: the earlier result comes back with repeated set. Pass true to make the same change a second time on purpose.
removeNoIds of rows to take off, from get_list.
updateNoChanges to rows that exist, each by id.
foldersNoChanges to folders that exist.
edit_linkNoThe list's edit link, whole (mahonia.app/e/CODE#token). The part after # is the write capability. Leave it out to name a list filed under the signed-in account by share_code instead.
share_codeNoInstead of the edit link: the share code or share link of a list filed under the connector's account, as get_list with no share_code gives it. Takes a sign-in with read-and-change access, and reaches only the lists that account has filed.

Output Schema

NameRequiredDescriptionDefault
unitYesThe unit the list displays in. Weights are in grams regardless.
addedYesRows added, nested ones counted.
datesYes
titleYesUser text.
trailYes
totalsYesWhole grams, summed over every row of the list.
foldersYesEvery folder's name, in the list's order, after the change.
removedYesRows taken off: by remove, with a removed group, or with a removed folder.
updatedYesRows changed, moved or regrouped.
repeatedYesTrue when this call, with rows to add, repeated one made in the last ten minutes: nothing was done again, and the figures are that call's. Pass again: true to do it a second time.
share_linkYes
folders_madeYesFolders that didn't exist and were made for rows named into them.
folders_changedYesFolders renamed, reordered, reclassified or removed.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: atomic all-or-nothing validation, the fixed order of list/folders/add/update/remove, cascading folder removal, empty-string clearing, catalog-link ownership rules, and retry deduplication with the 'again' override. These details materially help an agent predict destructive and non-idempotent effects, consistent with destructiveHint=true and idempotentHint=false.

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?

The description is front-loaded with purpose and densely organized by operation, with no obvious filler. It is long and clause-heavy rather than scannable, but the length is justified by the tool's complexity and the need to explain atomic multi-part edits.

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?

Given the 8 optional parameters, nested objects, full schema coverage, annotations, and an output schema, the description covers the important missing context: access via edit link or share code, ordering, atomicity, retry behavior, and catalog-link side effects. No essential agent-facing behavior appears omitted.

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. The description still adds cross-parameter meaning: the order in which list, folders, add, update, and remove are applied, the all-or-nothing validation rule, and the fact that removing a folder removes its rows. Much individual field semantics are already in 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?

The description states a specific verb and resource: 'Changes a list that already exists,' and emphasizes the multi-part scope 'all of it in one call.' It implicitly distinguishes from create_list by requiring an existing list and from get_list by describing mutations rather than retrieval.

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 clear usage context: existing lists only, edit link or share code for access, and references get_list and search_catalog for ids. However, it does not explicitly say when to use create_list instead, nor does it spell out exclusions beyond the existing-list condition.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.