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

With no annotations, the description carries the full disclosure burden and does well: it states the initial state of new items (unchecked), that listName surfaces in a permission prompt for user confirmation, the duplicate-avoidance constraint, and the return format. What it omits is what happens on partial failure or whether any existing data can be overwritten, which keeps it from a 5.

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

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

The core action and state effect are front-loaded in the first clause, and each subsequent sentence adds a distinct, actionable rule (field formatting, pre-check, branch handling, return format). No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Three required parameters at full coverage, no output schema — and the description compensates by stating 'Returns the added items in get_items format', which tells the agent what it gets back. The add/ask/replace workflow covers the main ambiguity; only failure and concurrency behavior remain unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the nested item fields are already documented in detail, so the schema does the heavy lifting. The description's naming rule ('only the product in name… never the quantity inside the name') is a useful reinforcement of a real failure mode but restates what the schema already says, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource and scope: 'Add one or more items to a list in a single call', plus the state effect ('new items start unchecked'). It implicitly separates itself from edit_items via the add-vs-modify workflow, but never names that sibling explicitly, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit preconditions and branching logic: call get_items first to check for an existing item, untick-and-set if checked, ask the user to add-or-replace if unchecked, and never create a duplicate row. This is a complete decision procedure rather than a vague hint, and it names the alternative tool (get_items) to use.

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

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

With no annotations, the description carries the full burden and does so: it declares irreversibility, mandates user confirmation before bulk/whole-list deletion, explains that confirmName and listName drive a permission prompt and are not sent to the API, and describes the return shape. These are exactly the behavioral traits an agent needs before invoking 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.

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

Front-loads the destructive permanence warning, then sequencing and alternatives. Every sentence earns its place, though the "clear bought items" instruction is slightly clause-heavy and could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by stating "Returns the deleted items in get_items format." Combined with the confirmation and ID-provenance guidance, an agent has everything needed to call this destructive tool safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a cross-parameter rule not present in the schema: "Always pass confirmName alongside each itemId," plus the provenance rule for itemIds. These elevate it above the schema-only baseline, though the per-field nuances of confirmName formatting remain schema-side.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: "Permanently delete items from a list; this can't be undone." It also explicitly distinguishes itself from edit_items (ticking off) and implicitly from delete_list, so an agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use triggers ("added by mistake, no longer needed", "asks to clear bought items - then delete only the checked ones"), a when-not-to-use alternative ("To mark something as bought, tick it off with edit_items instead"), and a prerequisite step ("Get itemIds from get_items"). 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.

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

No annotations are provided, so the description carries the full burden, and it delivers: the deletion is a soft delete restorable from the app trash, and on a shared list it removes the list for every collaborator. It also discloses the required confirmation UX, which is behavioral context an agent cannot get from any structured field.

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

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

Three sentences, all load-bearing: impact and reversibility first, then shared-list scope, then the confirmation requirement and the alternative tool. No repetition of the tool name or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter destructive tool with no output schema, everything an agent needs is present: reversibility, cross-user impact, the pre-call confirmation rule, and the sibling that handles the adjacent case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the non-obvious note that listName is only for the permission prompt and is not sent to the API. The description reinforces 'naming the list' but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Move a whole shopping list to the Listonic trash') and immediately scopes it against the sibling delete_items, which deletes items instead of the list. An agent can distinguish this from delete_items and rename_list without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative ('To delete items but keep the list, use delete_items instead') and the condition that selects it. It also states a hard prerequisite ('Always confirm with the user, naming the list, before calling') and points to get_lists for the shared-status check that determines blast radius.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden and does well: it discloses result ordering (unchecked first, then checked), the exact row format including itemId, and that several rows can share a name. It falls short of a 5 because it never explicitly states the tool is read-only with no side effects, nor how it behaves for an empty or missing list.

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

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

It is front-loaded with purpose, then result format, then usage rules, and nearly every sentence earns its place. It is somewhat sprawling, mixing output format, duplicate-name handling, and multi-row editing policy into one block, which keeps it just short of 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description must explain return values and behavior — and it does, covering ordering, row format, itemIds, and duplicate-name semantics. For a two-parameter read tool, an agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so listId and listName are already fully documented, including that listName is shown in the permission prompt and not sent to the API. The description adds no semantic detail about the parameters themselves, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get every item on one list') and immediately distinguishes this tool's scope from list-level siblings by describing the per-item result. An agent can tell exactly what it retrieves without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use rules: call before edit_items/delete_items to obtain itemIds, before add_items to avoid duplicates, report only unchecked items when asked what to buy, and ask which row when several match. It names sibling tools and the conditions that select them, leaving little to inference.

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

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: it discloses the return format, the own/shared visibility scope, and hard capability limits (no categories, no item notes, no list creation, no cross-list moves). It never explicitly states that the call is read-only/has no side effects, and says nothing about empty-state behavior, which is the remaining gap for a zero-annotation tool.

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

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

Front-loaded with what it returns, then the 'call this first' rule, then disambiguation, then capability limits. Four sentences, each doing distinct work with no repetition of the tool name or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by spelling out the exact line format '[listId] name (private|shared) - N unchecked'. Combined with the mandatory-first-call rule and the capability exclusions, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed and instead spends its space explaining the output line format, which is the only thing an agent must interpret here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List every shopping list') plus the exact scope ('own and shared'), which is precisely what separates it from get_items and the mutation siblings. It even specifies the per-line return shape, so an agent knows what it will get before calling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit sequencing rule: 'Call this first - every other tool needs a listId from here.' It also gives a disambiguation procedure ('match the user's wording... if more than one list could fit, ask which one') and tells the agent what to say when a requested capability is unsupported, which keeps the agent from hunting for nonexistent siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the consequence that a new name on a shared list is visible to all sharers, which tells the agent this is externally observable. However, it never states permission/ownership requirements, what happens if listId is invalid, or whether the rename is reversible — significant gaps for a mutation with zero annotation coverage.

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

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

Three short sentences, front-loaded with the action and then the impact, with no filler. The create-list caveat is slightly tangential to renaming but earns its place as a guardrail against a wrong tool call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three fully documented required parameters and no output schema, the description covers purpose, visibility side effect, and an adjacent-operation boundary — enough for correct invocation. Missing error/permission behavior keeps it short of a 5 on a mutation tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains that listName is the current name (confirm-only, not sent to the API) and that listId comes from get_lists. The description adds nothing about parameters beyond pointing implicitly at the list being renamed, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Rename an existing shopping list') with unambiguous scope — the list must already exist. No sibling tool performs renaming, so the agent can distinguish it immediately from edit_items, add_items, or delete_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context for use (renaming an existing list) plus an explicit exclusion: this server can't create lists, so the agent should direct the user to the Listonic app. That boundary guidance prevents a misfire, though it doesn't name a sibling tool or state prerequisites for renaming.

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