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

No annotations exist, so the description carries the disclosure burden, and it does substantial work: 100 MB cap for path uploads vs 10 MB decoded for base64, extension-driven MIME typing, and sanitization of unsafe filename characters. It omits error behavior (what happens on size overflow or a missing file) and any permission/auth prerequisites, keeping it short of 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?

Front-loaded with the two-source distinction and numbered for scanability; nearly every clause carries a constraint an agent needs. It is a single dense paragraph, so the return-value and card-identification facts get buried at the tail rather than being surfaced as separate structure.

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 fills that gap by naming the returned shape ({ id, filename, mime, size, ..., boardId }) and a concrete downstream use (feeding the id to kanbini_update_card as coverAttachmentId). Remaining gaps are auth requirements and failure modes for oversized or missing files.

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?

With schema description coverage at 17%, the description must compensate and it does: every meaningful parameter gets semantics beyond its type — `path` must be absolute and is copied in, `content` is agent-produced inline data, `encoding` defaults to utf8 and gates the size limit, `filename` dictates file type. The one schema-documented field (boardId) is reinforced rather than repeated.

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 ("Attach a file to a card") and immediately enumerates the two mutually exclusive creation modes, which distinguishes it from siblings like kanbini_delete_attachment. An agent can tell exactly what this tool produces — a stored attachment record.

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 routes between sources: use `path` for files already on disk, `filename`+`content` for data the agent produces itself, with `encoding` guidance splitting utf8 (notes/CSV/code) from base64 (small binaries). It also gives both legitimate ways to identify a card (id, or number + boardId), so there is no ambiguity about when each parameter applies.

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 well: it discloses idempotency ("Adding a link that already exists does nothing"), the rejection rules for self-links and cycles, the cross-board allowance, the user-visible blocked state, and that the change is undoable in the app. That is exactly the behavioral context an agent needs before mutating state.

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 critical facts — what the link means, idempotency, and rejection rules — are front-loaded, and every sentence carries information. The final sentence about id-vs-number referencing is dense and slightly convoluted, but its content is necessary given the thin schema.

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, yet the description still covers the resulting state (card shows blocked), where links are readable (blockedBy/blocking), idempotency, failure modes, and undo. Nothing an agent needs to call this correctly is missing.

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 only 33%, but the description fully compensates: it explains that a card may be identified by id or by number (`#142`) plus `boardId`, that both numbers must belong to that board, and that a cross-board blocker must be given by id. This resolves the ambiguity of the undocumented `cardId` and `blockerId` fields.

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?

Opens with a specific verb and resource: "Record that card `cardId` waits on card `blockerId` (a 'blocked by' link)." It immediately distinguishes the operation from the sibling kanbini_remove_blocker by framing the direction of the relationship (blocked-by vs blocking).

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-it-fails conditions (same id, direct or transitive cycles), notes idempotency on duplicate links, and permits cross-board links. It also routes the agent to kanbini_get_card / kanbini_get_board for inspecting existing links. It never names kanbini_remove_blocker as the inverse operation, so routing to the sibling for removal 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?

With zero annotations, the description carries the full behavioral burden, and it only discloses the return shape. It doesn't say whether the item goes to the end of the list (implied by 'append' but unstated), whether duplicate text is allowed, what happens with an invalid checklistId, or whether any permissions are needed.

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?

Two short sentences, front-loaded with the action and followed by the return value. There is no filler, though the brevity edges into under-specification rather than true economy.

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 an unannotated mutation tool with no output schema and 0% parameter coverage, this is thin. The return shape is a genuine plus, but ordering semantics, error conditions, and parameter meaning are all absent.

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 0%, so the description must compensate for the two undocumented parameters. It says nothing about 'text' (length, formatting) or 'checklistId' (where to obtain it), leaving both purely reliant on self-explanatory names.

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 and resource ('Append an item to an existing checklist'), which clearly distinguishes it from the sibling kanbini_create_checklist by requiring an existing checklist. The only mild gap is that it never names toggle_checklist_item as the contrasting operation.

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?

There is no explicit when-to-use guidance or mention of alternatives. The phrase 'existing checklist' implies a prerequisite that a checklist must already exist (i.e., use create_checklist first), but the agent has to infer that entirely.

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 present, the description does the heavy lifting: it discloses that nothing is deleted, that the board disappears from the home picker but remains reachable via "Show archived", and that contained cards stop appearing in search. It omits permission/auth requirements and doesn't state whether the operation is idempotent or what happens when archiving an already-archived board.

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 tight sentences: the action and its parameter mapping come first, side effects second, and the sibling-tool caveat last. No 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 simple two-parameter, non-destructive toggle with no output schema, the description covers the state change, reachability of the archived board, search implications, and how to retrieve archived boards. Nothing essential for a correct call is missing.

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 0%, so the description must define the parameters — and it explicitly binds `archived: true` to archiving and `archived: false` to restoring, which is the key semantic an agent needs. The `id` parameter is left uncharacterized (though obviously the board identifier).

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 pair (archive/restore) plus the resource (board), and immediately binds each mode to a parameter value. This is clearly distinguishable from kanbini_update_board, kanbini_archive_list and kanbini_archive_card.

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?

Explains the user-visible consequences of each mode (hidden from home picker, cards drop out of search) and notes that kanbini_list_boards still returns archived boards, which is useful routing context. It does not explicitly say when to prefer this over kanbini_update_board or state any preconditions/exclusions.

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 that the card vanishes from board, search, and counts, that position/checklists/comments/attachments survive, and that restore is exact. The only gap is that it doesn't mention any permission or failure conditions, which for a mutation tool would be the last missing piece.

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 operation and its reversibility are front-loaded, and every sentence carries information. It runs slightly long by folding user-facing notification policy into the same paragraph as parameter semantics, but there is no 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 3-parameter mutation tool with no annotations and no output schema, the description covers effects, reversibility, discovery path, the preferred alternative, and the id-vs-number addressing scheme. An agent has everything needed to call it correctly and to report the result accurately.

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 only 33% (only boardId documented), but the description compensates fully: it explains archived=true vs false semantics, and that id may be either a card id or a number like `#142` paired with boardId. All three parameters gain meaning beyond the raw 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 precise verb pair (archive/restore) mapped directly onto the boolean parameter, and names the exact resource. It is clearly distinguishable from siblings such as kanbini_delete_card and kanbini_archive_list, which are either named or implied by the card-specific scope.

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 routes the agent: 'Prefer this over kanbini_delete_card when the user wants a card "out of the way"', and points to kanbini_list_archived for retrieval. Both the when-to-use and the alternative are stated rather than inferred.

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 well: it discloses that archived lists and their cards vanish from the board, search and counts, that 'nothing is deleted', and that restore returns the list to its original slot with cards. Missing only authorization/ownership requirements and what the call returns.

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 mode mapping and scope come first, effects second, and the user-facing recovery path last. Every sentence adds information; nothing is redundant with the name or schema.

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 mutation with no annotations and no output schema, the side-effect, reversibility, and user-recovery details are thorough. Only the id source and any permission expectations are absent.

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 0%, so the description must compensate; it fully explains the boolean's meaning and consequences. The 'id' parameter's origin (where to obtain a list id) is left implicit, which is the one remaining gap.

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 pair and resource: 'Archive (archived: true) or restore (archived: false) a whole list (column).' The '(column)' gloss removes ambiguity, and 'whole list' distinguishes it from the sibling kanbini_archive_card.

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 clearly encodes which argument value selects which mode (true=archive, false=restore) and points to kanbini_list_archived as the discovery counterpart. It stops short of saying when to prefer this over kanbini_update_list or kanbini_archive_board, so no explicit exclusions.

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 enumerates copied fields, states what does NOT copy (comments, activity, 'waiting on' links), explains cross-board label remapping (same name, or new label in same colour), and declares the return value { id, boardId } plus the new card number. Only missing piece is any permission/auth note, which is minor.

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 the core action, then rules, then return value. Dense and mostly waste-free, though the 'Position works like kanbini_move_card' explanation plus the worked example is slightly repetitive.

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 6-param mutation tool with no annotations and no output schema, the description covers copy semantics, exclusion rules, ordering semantics, card addressing, and the return shape. An agent has everything needed to invoke it correctly.

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 only 50% (id, title, toListId undocumented), but the description compensates: it explains that `id` accepts a card id or a number like `#142` paired with `boardId`, that `title` overrides the copied title, and it restates beforeId/afterId as strictly above/below the copy. This adds real meaning 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?

Opens with a specific verb+resource ('Make a copy of a card') and states the scope ('in any list, on this board or another one'), which separates it from kanbini_create_card and kanbini_move_card. The enumeration of what is copied makes the operation's exact semantics unambiguous.

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 selection guidance for the optional parameters: use beforeId/afterId for placement, omit both for end of list, and 'to put the copy right under the original, pass the original as beforeId'. It also explains when boardId is needed (only when naming a card by number). It stops short of explicitly contrasting with kanbini_create_card as an alternative.

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 disclosure burden and does well: it states the board is created empty, that it lands in a hidden default project, and that the return is { id, boardId } with both equal to the new board's id. It does not address name collisions, permissions/auth, or whether the creation is reversible by delete — minor gaps for a non-destructive create.

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?

Four tight sentences, front-loaded with what is created and what it contains, then params, return shape, project side effect, and next steps in a logical order. No sentence is 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 annotations and no output schema exist, so the description had to cover semantics, side effects, return values, and sequencing — and it does all four. For a two-parameter create tool, nothing an agent needs in order to call it correctly is missing.

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 0%, yet the description fully compensates: `name` is identified as the required board title and `description` as an optional short blurb shown on the home picker. That adds UI-level meaning the bare string types do not convey.

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 ('Create a new empty board') and immediately disambiguates scope with '(no lists, no cards)', which distinguishes it from kanbini_create_list and kanbini_create_card. An agent can tell exactly what this tool produces without inspecting 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 an explicit follow-on workflow: 'Add columns next with kanbini_create_list, then populate them with kanbini_create_card', naming the alternatives and when each applies. It also discloses the implicit placement rule ('added to Kanbini's default project automatically'), removing the need for an agent to look for a project argument.

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 real weight: it discloses the return value ({ id, boardId }), the placement at the end of a list, and the important caveat that wipLimit is advisory and not enforced server-side. It doesn't mention permissions or failure modes, but the disclosed behaviors are substantial.

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 the core action, then guidance and caveats. Dense but every sentence adds value; only the wipLimit sentence is long, and it covers a non-obvious behavior worth the space.

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?

Despite no annotations and no output schema, the description covers the return shape, placement semantics, sibling routing, optional parameter behavior, and a non-enforced constraint. An agent has what it needs to call this correctly.

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 0%, so the description must compensate. It explains that priority is optional, gives the omission semantics ('omit for unprioritised'), and ties listId to the board lookup. It adds meaningful intent beyond the bare schema, though title constraints remain implicit.

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 plus placement semantics: 'Create a new card at the end of a list.' It also names the return shape and distinguishes itself from kanbini_update_card, which handles the description and other fields.

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 routes the agent: call kanbini_get_board first to obtain a listId, and use kanbini_update_card for subsequent field changes. It also states the wipLimit precondition and what to do before adding when a limit is set.

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 exist, so the description carries the full burden. It does disclose the return shape ("Returns { id, boardId }") and the card-addressing convention, which is more than many create tools say. However, it says nothing about permissions, duplicate checklist names, or whether creation is reversible, leaving meaningful behavioral gaps for a mutation 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?

Three tight sentences, all front-loaded: purpose first, then the return value and follow-up tool, then the parameter addressing rule. Every sentence carries information an agent needs and there is no 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?

With no annotations and no output schema, the description supplies the missing return shape and the card-addressing rule, which is the critical gap for this tool. What remains underspecified is the permission/duplication behavior of creating a checklist, a modest gap for a simple create operation.

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 only 33%, with cardId undocumented in the schema. The description compensates by explaining that a card can be given by id or by number (#142) together with boardId, which directly disambiguates the two opaque string parameters. The final 'name' parameter is left implicit but is self-evident from the tool purpose.

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 and resource ("Create a new checklist on a card") and immediately distinguishes itself from the fraternal item-level tools by pointing to kanbini_add_checklist_item as the populate step. An agent can tell this apart from rename/delete checklist tools 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?

It gives a clear workflow context: create here, then use the returned id with kanbini_add_checklist_item to populate it. It also explains the two ways to address a card. It stops short of explicit when-not-to-use guidance (e.g. versus rename_checklist), so it is not a 5.

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 disclose key traits: labels are board-scoped and the returned id is only valid on THAT board, and the return shape is stated. It omits error behavior, whether duplicate names are rejected, and any permission requirements, which for a create mutation keeps it short of 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?

Four sentences, all front-loaded and purposeful: purpose, scoping/reuse rule, return value, then palette constraint. The final sentence is long and partly redundant with the schema's color description, which is the only waste.

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 what an agent needs to call it correctly — scope, reuse check, return shape (there is no output schema, so stating { id, boardId } is valuable), and enum-free palette values. Missing failure/permission semantics, but complete for a simple 3-param create.

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 only 33% — name and boardId have no schema descriptions — and the description compensates only implicitly (board scope for boardId, nothing on name beyond the field label). The colour palette sentence largely repeats the color property's existing schema description, adding no new semantics.

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?

Starts with a specific verb+resource ("Create a new label on a board") and immediately scopes it as board-level, which cleanly separates it from update_label/delete_label and from kanbini_set_card_labels, which is named explicitly as the card-association tool.

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 an explicit pre-call rule ("Check the board view's labels[] first so you reuse an existing label instead of making a near-duplicate") plus a named alternative for the adjacent action (kanbini_set_card_labels). Both the when-to-use and when-to-avoid-creating conditions are stated.

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 does disclose two real behavioral facts: the new list is appended at the right end, and the call returns { id, boardId }. It does not cover permissions/authorization, whether the name must be unique on the board, or failure modes for an invalid boardId, which matters for an unannotated mutation 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?

Three short sentences, front-loaded with the action and placement, then chained consequences. No filler or restatement of the title.

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 tool with no output schema, the description supplies the return shape, the append position, and the id-chaining needed for follow-up calls. Only permission/error behavior is missing, which is a modest gap.

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 0%, so the description must carry the load. It usefully explains the provenance of boardId, but the 'name' parameter is left entirely to the schema's minLength:1 with no note on uniqueness, trimming, or length limits.

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 ('Create a new list (column)') plus the exact placement semantics ('at the right end of a board'), which also implicitly distinguishes it from kanbini_move_list and kanbini_update_list. An agent knows precisely what effect the call has 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 concrete workflow context: where boardId comes from (kanbini_list_boards or a fresh kanbini_create_board) and how the result feeds kanbini_create_card. It stops short of saying when not to use this tool, e.g. when a similar column already exists or that update_list/move_list handle modification.

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 available, the description carries the full burden and does it well: it discloses what is destroyed (the file), the side effect on card state (cover cleared), the limits of undo (entry restored, file not), and the need to confirm before calling. That is exactly the context an agent needs to avoid an unrecoverable action.

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, zero filler, with the destructive effect and its irreversibility front-loaded ahead of the id-provenance tip. Every sentence adds a distinct fact.

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 one-parameter destructive tool with no annotations and no output schema, the description supplies everything material: what is removed, side effects, undo limits, and id provenance. Nothing an agent needs in order to call it safely is missing.

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 0% and the lone parameter is undocumented, but the description compensates by telling the agent where attachment ids come from (kanbini_get_card), which is the key semantic an agent needs. It does not state the id format, keeping it short of a 5.

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 ("Delete an attachment from its card") and adds scope the name doesn't carry: the stored file goes too. It is clearly distinct from the other mutating siblings like kanbini_add_attachment or kanbini_archive_card.

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 real operational guidance: confirm intent first because the file cannot be restored, and points to kanbini_get_card as the source of ids. There is no explicit 'use X instead when' clause, but for a delete with no analogous sibling the routing information given covers the practical need.

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 it delivers the key behavioral facts: the deletion is cascading (lists, cards, labels go too) and it is recoverable via Ctrl+Z in the app, which meaningfully changes the risk calculus of a destructive call. It stops short of stating permission requirements or whether the return/confirmation behaves differently for boards with content.

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: what it destroys first, routing/alternative second, recoverability last. No restatement of the title and no 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 one-parameter destructive tool with no annotations and no output schema, the description covers destruction scope, the safer alternative, and reversibility — everything needed to avoid a mistaken call. Only access-control expectations and the shape of the result are left unstated.

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 0%, so the single `id` parameter is documented nowhere except the description, and the description never explicitly says the parameter is the board identifier or what format it takes. "Confirm the board by name first" implies the id resolves to a specific board but leaves the agent to infer that `id` is the board's id rather than, say, a name.

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?

"Permanently delete a board with all of its lists, cards and labels" names a specific verb, resource and cascade scope in one clause. It is immediately distinguishable from sibling kanbini_archive_board and from the list/card level delete tools.

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 names the preferred alternative (kanbini_archive_board), states the condition that justifies this tool instead ("unless the user clearly asks for it to be deleted"), and adds a procedural precondition ("confirm the board by name first"). This is explicit when/when-not guidance rather than implied usage.

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 well: it discloses FK-cascade removal of checklists, comments and attachment rows, and that files persist on disk until a GC sweep. The phrase "cannot be restored from the UI" is slightly equivocal about whether an API restore path exists, which keeps this 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?

Three sentences, front-loaded with the destructive nature and side effects before the identification rules. Dense with information and no filler, though the final sentence is a touch convoluted in how it merges the two identification modes.

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 annotations and no output schema, the description covers consequences, irreversibility and argument formats well. Minor gaps remain around return value and error behavior for a nonexistent card.

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 50% and the `id` parameter has no schema description at all; the description compensates by explaining that a card may be identified by id or by its displayed number (`#142`) paired with `boardId`. That is exactly the disambiguation the bare schema lacks.

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?

"Permanently delete a card" gives a specific verb and resource, and "Permanently" implicitly separates it from the sibling archive_card. It stops short of naming archive_card as the recoverable alternative, so the contrast is inferred rather than stated.

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?

The description advises confirming intent before calling, which is real usage guidance for an irreversible operation. However, it never routes the agent to the sibling that should be preferred when reversibility matters (archive_card), and gives no preconditions such as required permissions or what happens on a bad id.

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 disclose the two facts an agent most needs: deletion cascades to all items, and the action is reversible via app-level undo. It is silent on permissions, whether undo is time-limited or programmatic, and what the response contains, keeping it out of the top band.

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?

Two short sentences with no waste; the destructive scope is front-loaded and the reversibility note follows immediately. Every sentence earns its place.

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?

The behavioral picture (cascade delete, undo available) is adequately covered for a mutation tool with no annotations and no output schema. The parameter gap is what keeps it at minimum-viable: nothing tells the agent what 'id' refers to.

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?

There is one required parameter 'id' with 0% schema description coverage, and the description never mentions it, its format, or where to obtain it. With no help in either the schema or the prose, the agent is left to guess that it is the checklist identifier.

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 ('Delete a whole checklist') and scopes it ('with all of its items'), which implicitly separates it from the sibling kanbini_delete_checklist_item that removes a single item. It doesn't name that sibling explicitly, so it falls just short of full differentiation.

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?

Usage is only implied: the agent must infer that this is the right tool when the entire checklist should go rather than one item. There is no explicit 'use this instead of kanbini_delete_checklist_item when…' guidance or prerequisite statement.

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 does usefully disclose reversibility ("The user can undo in the app"), but says nothing about permissions needed, what happens to item ordering/positions in the checklist, or whether the undo applies to API calls or only UI actions.

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?

Two short sentences, front-loaded with the action and followed by the undo caveat. Nothing is wasted, though the second sentence could be tightened into the first for maximum density.

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?

A destructive tool with no annotations, no output schema, and an undocumented sole parameter. The description leaves the agent without confirmation of what identifier to supply or what a successful deletion returns/affects, which is more than a minor gap for a delete operation.

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 single parameter `id` has 0% schema description coverage, and the description does not clarify whether it is the checklist item id, the parent checklist id, or a card id. For a destructive call this ambiguity is meaningful, and the description does nothing to compensate for the coverage gap.

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?

"Remove one item from a checklist" gives a specific verb (remove) and a precise resource scope (a single checklist item), which implicitly separates it from kanbini_delete_checklist and kanbini_delete_card. It does not explicitly name those siblings, so differentiation requires the agent to infer from the name.

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?

No guidance on when to choose this over kanbini_update_checklist_item, kanbini_move_checklist_item, or kanbini_delete_checklist. There are no prerequisites or exclusions stated; the agent must infer usage purely from the tool name.

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 add valuable traits: the operation is reversible ("The user can undo in the app") and there is a confirmation/consent expectation for the user's own comments. It says nothing about whether deleting another author's comment needs elevated rights, what happens if the id does not exist, or the response shape.

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, action front-loaded, then the conditional rule, then the reversibility note. Nothing is redundant and every sentence adds information the agent did not already have.

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 single-parameter delete with no output schema, the description covers purpose, consent policy, and reversibility — enough to call it correctly in most cases. The one real hole is the identity of the `id` argument, which is the only input the tool takes.

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 0% and the sole parameter is bare `id`. The description never clarifies whether that id is the comment id or the card id, nor the expected format. That ambiguity is exactly the kind of thing the description must compensate for when the schema does not.

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 ("Delete a comment from a card"), which cleanly separates it from the other destroy tools in the sibling list (delete_card, delete_attachment, delete_checklist). It does not explicitly cross-reference those siblings, but the resource is unambiguous enough that no agent would confuse them.

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 a real usage rule: comments with author null belong to the user and should only be deleted on request. That is a meaningful precondition rather than generic filler. It stops short of naming alternatives (update_comment for edits, or how to handle other users' comments requiring explicit instruction), so it is clear context without full exclusion guidance.

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 most of it well: it discloses the cascade to every card carrying the label and the in-app undo path (Ctrl+Z) that restores it to the same cards. It omits permission/auth requirements and says nothing about what the call returns or whether undo remains available across sync/session boundaries.

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 direct action and escalating to the destructive scope and the caution. Nothing is redundant and the most decision-relevant fact (EVERY card) is capitalized for emphasis.

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 one-parameter destructive tool with no annotations and no output schema, the description covers the two things an agent most needs: scope of destruction and recoverability. Only the ambiguity of the `id` argument and post-undo state keep it from being fully complete.

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 single `id` parameter has 0% schema description coverage, so the description is the only place meaning could be added, and it never clarifies that the id is a label id rather than a board or card id. The tool name makes the intent inferable, but this is a real compensation gap at low coverage.

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 ('Delete a label') plus its scope ('from its board'), which cleanly separates it from create_label and update_label among the siblings. The cascade detail ('removed from EVERY card') further pins down what the operation actually does.

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 a concrete usage condition: confirm intent first when the label is in use. It doesn't name alternative tools or say when not to use it, but no sibling is a plausible substitute for a delete, so the missing exclusion matters little.

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 does so: it discloses permanence, the cascading deletion of all cards, and the mitigation that the user can undo via Ctrl+Z on that board. It also prescribes a confirmation behavior (count the affected cards) before executing, which is beyond what any structured field conveys.

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 tight sentences, front-loaded with the destruction and cascade, then the alternative, then the undo caveat. No filler, and the most agent-critical facts come first.

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 one-parameter destructive delete with no output schema, the description covers consequences, alternatives, and recoverability — everything needed to decide and act safely. It stops short of naming the parameter itself, which is the only remaining gap.

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 0% for the single `id` parameter, and the description never states that `id` is the list identifier, though this is strongly inferable from the tool name and the "list" phrasing. The behavior that matters most (cascading card deletion tied to this id) is disclosed, which partly compensates for the undocumented parameter.

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 ("Permanently delete a list (column)") and immediately clarifies the cascade scope ("and every card in it"). The "(column)" gloss disambiguates board-list terminology, and the destructive framing separates it from kanbini_archive_list and kanbini_update_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?

Explicitly names the preferred alternative ("Prefer kanbini_archive_list unless the user asks for it to be deleted") and gives both the selection condition and the pre-call obligation to say how many cards go with it. This is exactly the when/when-not/alternatives structure a destructive sibling tool needs.

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 exist, so the description carries the full behavioral burden and does so unusually well: it discloses the section breakdown, ordering rules, per-item field set, the meaning of `blocked`, pagination-with-totals behavior, exclusion of archived cards/lists/boards, local-time semantics for 'today', and an offline fallback to the last on-disk export. These are exactly the non-obvious traits an agent cannot infer from structured fields.

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 the core purpose, and virtually every clause adds usable information. It is dense as one undivided block (~180 words) with section names, field lists, and caveats interleaved, so a light structural separation would improve scanability, but there is no filler to cut.

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?

With no annotations and no output schema, the description itself supplies the return shape, field semantics, ordering, defaults, exclusions, and degraded-mode behavior. Nothing an agent needs in order to call this correctly or interpret the result is missing.

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 0%, so the description must compensate, and it does: `limit` gets default 50 per section and max 100, `upcomingDays` default 7, `completedDays` default 7 plus newest-first ordering. It also clarifies that `totals` counts untrimmed cards, which is a semantic distinction no schema could convey.

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?

Opens with a concrete verb-and-resource framing ('What's on the user's plate, across every board in one call') and immediately enumerates the four returned sections, which distinguishes it from any per-board reading tool. An agent knows exactly what this produces 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 trigger phrasings ('what should I work on', 'what is overdue', 'what did I get done this week') and an explicit alternative to avoid ('instead of walking every board'). It stops short of naming specific sibling tools (e.g. list_boards/get_board or search_cards) and gives no when-not-to-use exclusion, so it is strong but not maximal.

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: archived cards excluded vs archived lists included with closed:true, display settings (collapsed, cardDensity, visibleCardLimit) do not truncate results, null return on bad id, and an offline fallback to the last on-disk export.

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 the return shape, then constraints in order of importance. Dense but nearly every clause adds operational value; the display-settings sentence is slightly long but prevents a real misuse (assuming truncated results).

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 and no annotations, yet the description covers return shape, archival behavior, id fallback, error case, and offline behavior. Only minor gaps (full card field list, id format) remain for a single-parameter read tool.

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 0%, so the description must compensate; it explains the omission default (first board) and the null case for a non-matching id. It doesn't specify the id format, but the semantics are largely covered for a single optional parameter.

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 ('Return one Kanbini board view') and enumerates the payload (project, lists, cards, labels), which clearly separates it from kanbini_list_boards and kanbini_get_card.

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 routes the agent: call kanbini_list_boards first when multiple boards may exist, use kanbini_list_archived for archived cards/lists, and notes the default behavior when boardId is omitted.

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 and does so well: it explains the missing-boardId error, null returns for nonexistent ids/numbers, and the fallback to the last on-disk export when the desktop app is closed. It also details archived-card support and the blocked/blocking semantics.

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 description is front-loaded with the core lookup behavior and remains organized despite its length. Because there is no output schema, much of the return-field detail earns its place, though the text is dense and could be trimmed slightly.

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 read tool with no annotations and no output schema, the description is complete: it covers input resolution, error/null behavior, archived cards, fallback behavior, returned fields, and blocker semantics. An agent has enough context to invoke it correctly.

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 0%, so the description must explain both parameters, and it does: `id` can be an id or a `#142`/`142` number, while `boardId` is needed for numbers because numbers are per board. The only small gap is that it does not explicitly say the number is passed in the `id` field.

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 states a specific verb and resource: return one Kanbini card by id or by its short number. It clearly distinguishes this lookup tool from list/search behavior and explains its role in resolving user-facing card numbers to ids needed by write tools.

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 clear when-to-use guidance, including that a number requires `boardId` and that `boardId` is ignored for an id. It also covers stale numbers and archived cards, though it does not explicitly contrast with `kanbini_search_cards` as the main alternative.

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 well: ordering (most recently touched first), the `listClosed` edge case, null for unknown boardId, and an offline fallback to the last on-disk export when the desktop app is closed. These are non-obvious behaviors an agent could not infer from the schema.

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?

Four sentences, each carrying distinct information: return shape, the listClosed caveat, the restore path, and the error/offline behaviors. The result structure is front-loaded and no sentence is 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?

There is no output schema, so the description must describe the return value, and it does: a `lists` group with live-card counts and a `cards` group with list names, plus the null and offline-fallback cases. Nothing essential for calling or interpreting the tool is missing.

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?

Only one parameter (boardId) and schema description coverage is 0%, so the description must supply meaning. It reveals the unknown-id behavior (returns null) but never states that boardId is required or what format an id takes, leaving part of the single parameter's semantics implicit.

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 (return what a board has archived) and enumerates the two result groups, `lists` and `cards`. It is clearly distinguishable from siblings like kanbini_get_board or kanbini_search_cards, which cover live content.

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 tells the agent what to do with the returned ids: use them with kanbini_archive_card / kanbini_archive_list with archived: false to restore. It also warns that restoring a card in an archived list is insufficient without also restoring the list. It does not contrast with live-content siblings, but the operational guidance is concrete.

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 explains that updatedAt blends the board timestamp with the newest activity-log entry (so array order is real recency), that an empty result is [] rather than an error, and that a closed desktop app causes a fallback to the last on-disk export with a response prefix notice.

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, front-loaded with the resource and return shape, then the usage directive, then edge cases. Every clause carries information an agent would otherwise have to discover by calling the tool.

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 and no annotations, so the description must cover return values and failure modes – and it does, including field list, empty-array semantics, sort order rationale, and degraded-mode behavior. Nothing needed to call this correctly is missing.

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 there is nothing for the description to disambiguate; the baseline for a 0-param schema applies. The description correctly implies no arguments are needed by framing the call as a full enumeration.

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 ("Enumerate every board in the database") and then enumerates the exact fields returned (id, name, description, archived flag, list/card counts, updatedAt). It also distinguishes itself from the nearest sibling by directing the agent to pass discovered boardIds to kanbini_get_board.

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?

"Use this first to discover boardIds before calling kanbini_get_board" gives explicit ordering and names the follow-up alternative. It does not address overlap with kanbini_list_archived, so an agent must still infer whether archived boards are included here (the presence of the archived flag only implies it).

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 well: neigbour resolution is server-side, wipLimit is not enforced, sortMode lists override the requested slot, and cross-board moves renumber the card and remap labels by name (creating one in the same colour if absent). These are non-obvious mutation side effects an agent could not infer from the name or schema.

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?

Long but almost every clause is load-bearing; placement mechanics are front-loaded before caveats. It is dense and parenthetical in places (the wipLimit and sortMode notes are spliced mid-paragraph), so it could be segmented more cleanly, but there is little wasted text.

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 5-parameter mutation tool with no annotations and no output schema, the description covers ordering, constraints, cross-board effects and where to verify the result (kanbini_get_card). Remaining gaps are minor: no mention of failure conditions such as moving into a list on an inaccessible board, and nothing about what the card's comments or attachments do on a cross-board move.

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 only 60% and the id and toListId properties have no schema descriptions at all, so the description must compensate. It explains the destination semantics of toListId, the above/below frame of reference for beforeId/afterId, the fact that one neighbour suffices, and critically that a card can be named by id or by number (#142) together with boardId, including the board-consistency requirement for neighbour references.

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?

Opens with a specific verb plus resource plus scope: move a card between lists or reorder within its current list. That cleanly separates it from kanbini_move_list and kanbini_move_checklist_item, and from kanbini_update_card, without the agent 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.

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

Gives explicit conditional recipes: beforeId for the card above, afterId for the card below, omit both to append, afterId-only for top placement, and the ordering strategy for placing several cards in sequence. It also names the situation where the tool will not behave as requested (non-null sortMode lists) and flags wipLimit as advisory, so the agent knows both when to use it and when the outcome may differ from the request.

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 present, so the description carries the full behavioral burden. It usefully discloses that `toChecklistId` may target a checklist on another card and how ordering resolves, but says nothing about permissions, what happens on invalid/stale ids, or whether the operation is reversible.

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?

Two sentences, front-loaded with the action and scope, followed by the ordering rules. No filler and no repetition of the title.

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 four-parameter mutation with no annotations and no output schema, the description covers the non-obvious parts: cross-checklist/cross-card targeting and the before/after/omitted ordering resolution. It leaves failure modes and side effects unstated, which is the main remaining gap.

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 50%: `beforeId`/`afterId` are already described in the schema and the description only reinforces them, while `id` and `toChecklistId` are undocumented in the schema. The description adds genuinely new meaning for `toChecklistId` (cross-card) and the one-or-none rule for before/after, but leaves `id` implicit.

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 checklist item') plus the two distinct scopes it covers: within its own checklist or into another checklist. An agent can distinguish this from kanbini_update_checklist_item or kanbini_add_checklist_item from the description alone.

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?

Clearly specifies the operating conditions: one of `beforeId`/`afterId` suffices, and omitting both appends to the end. It does not, however, state when to prefer this over the sibling `kanbini_update_checklist_item` (rename/edit) or that `toChecklistId` is required even for same-checklist reordering.

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 real work: it discloses server-side inference ("one neighbour is enough, the server works out the other") and a non-obvious constraint (closed lists retain their slot). It omits permission requirements and error behavior, which keeps it off 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?

Purpose is front-loaded, then semantics, then edge cases – a sensible progression with no filler sentences. It is dense but every clause carries information; minor overlap with the schema's beforeId/afterId descriptions is acceptable reinforcement.

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 3-parameter mutation tool with no annotations and no output schema, the description covers positioning semantics, prerequisites, and the closed-list edge case. What remains absent is failure/permission behavior, a modest gap rather than a blocking one.

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 67% and the description substantially compensates: it defines the left/right orientation from the moved list's point of view, the asymmetry rule for far-right vs far-left, and the same-board constraint. The `id` parameter is never described, but the tool name makes its meaning self-evident.

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 opening sentence gives a specific verb and resource ("Move a list (column) to a new position on its board") and the parenthetical disambiguates it from the many card/checklist-item move siblings. An agent can immediately tell this operates on columns, not cards.

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 explains the neighbour-based positioning model concretely, covers the far-right and far-left edge cases, and points to kanbini_get_board as the way to obtain the current order. It stops short of explicit exclusions (e.g. "not for reordering cards – use kanbini_move_card"), but the resource is unambiguous.

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 it does disclose real behavioral facts: the author field is forced to 'ai', the badge rendering consequence, and the literal-backslash-n escaping pitfall. It omits permissions/auth requirements, whether notifications fire, and any error behavior, so it is useful but not complete for a write 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 action, then the author/rendering behavior, then the Markdown gotcha, then the identifier formats. Four sentences with no filler, though the backslash-n warning is a little verbose relative to the rest.

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 3-parameter write tool with no annotations and no output schema, the description covers the important unknowns: who the author is, how the body is interpreted, and how the card is addressed. Only auth/permission and response-shape context are missing, which is a minor gap.

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 only 33% (only boardId is documented), so the description must compensate, and it does: it explains cardId accepts either an id or a `#142` number form, that boardId is required only in the number case, and that body is Markdown with specific escaping semantics. Every parameter gains meaning 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?

Opens with a specific verb+resource ("Post a comment on a card") that cleanly separates it from update_comment and delete_comment siblings. It doesn't explicitly name those siblings as alternatives, so it falls just short of a 5.

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?

Usage is implied rather than stated: the tool is for writing new comments, and the note that the author is auto-set to 'ai' hints at the intended AI-comment context. There is no explicit when-to-use/when-not or routing to kanbini_update_comment for edits, which an agent would have to infer.

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 at all, the description carries the full disclosure burden and does well: it declares idempotency ('Removing a link that doesn't exist does nothing') and reassures that 'Neither card changes otherwise.' It omits anything on permissions or what a successful call looks like.

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 action and directional semantics are front-loaded in the first sentence, with idempotency and naming conventions following. No filler sentences; each one adds distinct information.

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 small three-parameter mutation with no annotations and no output schema, the description covers direction, idempotency, side effects, and the card-naming convention. What is missing is minor: return value shape and whether auth or card state (e.g. archived cards) affects the call.

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 33%, so the description must compensate, and it does: it explains that a card may be referenced either by raw id or by its displayed number (`#142`) plus boardId. Only boardId already had schema documentation; the id-vs-number convention for cardId and blockerId is new information.

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 (remove) and resource (the blocking link between two cards) and defines the direction precisely: cardId waits on blockerId. That directional detail is exactly what distinguishes it from the sibling kanbini_add_blocker.

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?

Use is implied rather than stated: an agent can infer this is the inverse of kanbini_add_blocker, but the description never names that sibling or says when to prefer it. No prerequisites or exclusions are given either.

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 it does disclose the mutation (rename) and the source of the identifier. It says nothing about permissions, error behavior if the id is invalid, or what a successful rename returns, which are meaningful gaps for an unannotated mutation.

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?

A single short sentence, front-loaded with the action and resource, with the id-provenance hint parenthetically attached. Nothing is wasted.

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 simple two-parameter mutation with no output schema, the description supplies the essential missing context (where the checklist id comes from) and the action. Only the fate of the `name` parameter and post-call behavior are left 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 0%, so both `id` and `name` are bare types in the schema. The description clarifies that `id` is a checklist id obtained from kanbini_get_card, which adds real value, but it never states that `name` is the new checklist name or its constraints (min length 1), leaving half the parameters to inference.

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 (rename) and resource (a card's checklist), which distinguishes it from sibling checklist tools such as create_checklist, delete_checklist, and update_checklist_item. The scope ('a card's checklist') is unambiguous.

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?

The description tells the agent where the required id comes from (the `checklists` field of kanbini_get_card), which is a useful precondition. However, it gives no explicit when-to-use guidance or contrast with siblings like create_checklist or delete_checklist, so usage is only implied.

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 does so: it discloses result ordering (number, title, label, description, then recency), exclusions (archived cards and closed lists), the default/max limit, the per-board numbering caveat, and a degraded-mode fallback to the last on-disk export when the desktop app is closed. These are exactly the non-obvious traits an agent cannot infer from the schema.

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 the matching rule, then result shape, ordering, exclusions, and the follow-up tool — a logical order with no filler. It is dense to the point of being a single semicolon-chained block, which slightly hurts scanability for a two-parameter tool, but no sentence is expendable.

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 the description compensates by enumerating every returned field and matchKind values, plus ordering and exclusion rules. Combined with the fallback behavior and the next-step pointer, an agent has everything needed to call it and interpret results correctly.

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 0%, so the description must compensate and does: it defines `limit` semantics (default 50, max 100) and fully explains `query` behavior including substring matching fields and the `#142`/`142` numeric form. It also warns that numbers are per board and to check boardName, which is a semantic trap the schema cannot express.

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 ('Global card search') plus the exact matching rule (case-insensitive substring on title, description, label name). It is clearly distinguished from siblings like kanbini_get_card, which it explicitly routes to for full detail.

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?

Names the follow-up path explicitly ('Use cardId with kanbini_get_card to fetch full detail for any hit'), which tells the agent this is a discovery step, not a detail fetch. No explicit 'when not to use' guidance against other search-adjacent siblings, but the scope statement ('global... across all boards') implicitly rules out board-scoped lookups.

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 exist, so the description carries the full load, and it does well: it discloses the destructive semantic (the whole set is replaced, so prior labels are dropped), idempotency, that an empty array removes everything, and a server-side validation constraint (labels must belong to the card's board). It stops short of stating permissions/auth requirements or what happens on an invalid label id (error vs. silent skip).

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 core behavior and the empty-array escape hatch before the sourcing and addressing details. Dense but nearly waste-free; the card-addressing sentence is slightly crammed, mixing the id/number rule with label sourcing, but nothing is redundant.

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?

With no annotations and no output schema, the description must supply the behavioral contract, and it covers replacement semantics, validation, idempotency, and card addressing. Only the return value and error/failure behavior are unaddressed, which is a minor gap for a setter of this shape.

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 only 33% (only boardId is documented in the schema), but the description compensates for all three parameters: id may be a card id or a number like '#142', boardId is required only in the numeric case, and labelIds is the full replacement set where [] clears labels. No parameter is left ambiguous.

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: 'Replace the full set of label ids on a card', plus the key semantic twist that it is a full-set replacement and idempotent. This clearly separates it from sibling tools like kanbini_update_card (piecemeal edits) and kanbini_create_label (creates rather than assigns).

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 covers when to use it ('pass an empty array to remove all labels'), where the ids must come from (the board view's top-level labels[]), the precondition that labels must belong to the card's board, and names the alternative kanbini_create_label for labels that don't exist yet. That is when/when-not/alternatives all in one paragraph.

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 behavioral burden for a mutation tool. It explains the boolean effect but omits permissions, idempotency/already-set behavior, error conditions, and whether the item or card is affected.

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?

Two short sentences, front-loaded with the core action and no filler. The true/false semantics are stated efficiently.

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 a mutation tool with no annotations, no output schema, and zero schema description coverage, the description is too thin. An agent still lacks the meaning of id, permission/error expectations, and confirmation of the side effect.

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 0%, so the description must compensate for both parameters. It usefully explains the completed flag ('true to mark done, false to reopen') but says nothing about what the required id parameter identifies or what format it expects.

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 states a specific action ('Set the completed flag') and resource ('a checklist item'), so the tool's effect is clear. It does not explicitly differentiate from nearby siblings such as add_checklist_item or create_checklist, which keeps it from a 5.

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?

The description explains the meaning of true and false, but gives no guidance on when to use this tool versus related checklist/item operations. There is also no mention of prerequisites, such as the item needing to exist or valid id semantics.

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 real work: it declares patch/partial-update semantics and, critically, that null explicitly clears description and color — a destructive nuance the schema's anyOf only implies. It does not mention permissions, whether a rename affects references elsewhere, or failure modes for a non-existent board, which keeps it below 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?

Front-loaded with the verb and then one clause per field, so it scans well. The 14-item palette list is useful but partly duplicates the enum already present in the color schema branch, adding length without new information.

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 nested-object mutation tool with no annotations and no output schema, the description covers every updatable field, clearing semantics, and the archive alternative. It stops short of stating what the call returns or how it errors, which matters somewhat for a write tool.

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 0%, yet the description defines every patch field's meaning and side effect (renames, home-picker blurb, accent on card/header, favourites to top) plus null-clearing behavior and the accepted palette vocabulary. Only `id` is left implicit, which is a trivial gap.

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?

Opens with a specific verb+resource ('Patch a board') and immediately enumerates the exact fields being changed and what each one does. It also distinguishes itself from kanbini_archive_board, so an agent can separate it from the closest sibling 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.

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

'Omit fields you do not want to change' states the partial-update contract clearly, and 'To archive a board use kanbini_archive_board' routes the agent away from the most likely mistaken alternative. It does not cover prerequisites or when this is preferable to reading get_board first, so not a full 5.

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 zero annotations, the description carries the full burden and does substantial work: it explains that `collapsed` is purely a rendering concern that "hides nothing from you", that null clears fields, and details the non-obvious side effect of completing a repeating card (next card created in the working list, due one repeat out, fields and unticked checklists copied, rule moves). It stops short of stating permissions, error behavior, or whether the patch 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?

Front-loaded purpose followed by one clause per field, so every sentence maps to a parameter and earns its place. The repeat paragraph is dense and slightly over-long, but no sentence is 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 mutation tool with no annotations, no output schema, and a nested patch object, this covers nearly everything an agent needs to construct a correct call. The remaining gap is what the tool returns and whether the patch is atomic/partial on failure — neither is stated and nothing in structured data fills 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?

Schema coverage is only 33%, and the description fully compensates: Markdown line-break caveat, epoch-ms dueAt with null-to-clear, priority enum values, the repeat object shape with a concrete example, coverAttachmentId semantics, and how to address a card by id vs number+boardId. It adds real meaning the schema cannot express (null clears, backslash-n renders as text).

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?

Opens with a specific verb+resource ("Patch one or more card fields") and immediately enumerates exactly which fields are patchable, so an agent knows this is the field-mutation tool rather than move/archive/label siblings. The identity clause at the end (id or #number + boardId) further pins down scope.

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?

Implied usage only: "Omit fields you do not want to change" and the `collapsed` advice ("change it only when the user asks for a tidier board") are genuine usage constraints. But it never routes away from siblings — no mention that moving a card belongs to kanbini_move_card, labels to kanbini_set_card_labels, or archiving to kanbini_archive_card. An agent must infer the boundaries from the field list.

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; it does disclose the key PATCH-like trait that unspecified fields are left untouched. It says nothing about whether the update is reversible, what happens with an unknown id, or permission requirements, leaving meaningful behavioral gaps.

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 compact sentence with the mutability constraint front-loaded, followed by the omission rule. No filler and no repeated schema content.

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 small 3-parameter mutation tool with no annotations and no output schema, the description covers the editing surface but omits id semantics, error behavior, and the relationship to the toggle sibling required to disambiguate overlapping functionality.

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 0%, so the description must compensate; it does explain that text and completed are optional edits, but never clarifies that id is the checklist item identifier (as opposed to a card or checklist id), which is the most error-prone parameter 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 (change) and resource (checklist item) plus the exact fields affected (text, completed), which is far better than a tautology. However, it does not distinguish itself from sibling kanbini_toggle_checklist_item, which also sets completed, so an agent cannot tell from the description alone which one to prefer.

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?

'Omit what you do not want to change' gives clear partial-update guidance, but there is no statement of when to use this versus kanbini_toggle_checklist_item (ticking) or kanbini_move_checklist_item, nor any prerequisites such as the item needing to exist.

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 load and does so well: 'Replace' discloses that the existing body is overwritten (not appended), 'The user can undo in the app' discloses reversibility, and the author-null rule conveys an ownership/authorization caution. It does not state permission requirements or what is returned, 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?

Four short sentences, front-loaded with the action and immediately followed by the id source, so the reader gets the essential facts first. The ownership aside and parenthetical read as somewhat interleaved, but no sentence is wasted.

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 mutation with no annotations and no output schema, the description covers overwrite semantics, body format, ownership rules, and reversibility. Remaining gaps (permissions, error behavior, what the response contains) are modest for a tool this simple.

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 0%, so the description is the only source of parameter meaning. It supplies genuinely useful provenance for `id` (found in the `comments` of kanbini_get_card) and formatting for `body` (Markdown, with real line breaks). It does not say what the id string looks like or clarify body constraints beyond that, so compensation is partial.

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 ('Replace the text of a comment'), which cleanly separates it from the sibling comment tools kanbini_post_comment and kanbini_delete_comment. It also tells the agent exactly where the target id lives (the `comments` of kanbini_get_card), removing any ambiguity about what an id refers to.

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 a concrete usage constraint: comments the user wrote (author null) belong to them and should only be changed when they ask. That is real when-to-use guidance rather than filler. It stops short of naming alternatives (e.g. post_comment to add a new comment instead of overwriting), so it lands just below the explicit when/when-not/alternative tier.

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 provided, the description carries the burden and usefully discloses that changes propagate to every card using the label. It also covers partial-update semantics and palette-name usage, though it omits permission requirements, conflicts, and error behavior.

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 description is front-loaded, three sentences long, and every sentence adds useful information. There is no repetition or unnecessary preamble.

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 nested-parameter mutation tool with no annotations or output schema, the description provides the important behavioral context: field effects, partial updates, and the label-wide impact. It stops short of covering permissions or failure modes, but is otherwise sufficient to call the tool correctly.

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?

Despite low top-level schema description coverage, the description explains what the nested patch fields do: name renames and color recolours. It also explains omission semantics for partial updates, though it does not explicitly define the id parameter.

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 states a specific verb and resource: patching a label via rename or recolour. It also clarifies the observable effect on every card carrying the label, which distinguishes it from create_label and delete_label without ambiguity.

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 clearly explains the patch-style usage by saying to omit fields that should not change. It does not explicitly name alternatives or exclusions, but the context for when to use this tool is strong.

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 well: it discloses that wipLimit is NOT enforced for writes ("check the card count yourself before adding"), that switching sortMode back to "manual" freezes the sorted order, that cardDensity can be overridden per card via kanbini_update_card, and that visibleCardLimit is display-only because kanbini_get_board returns every card. These are exactly the non-obvious side effects an agent would otherwise get wrong.

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 the core action, then one clause per field, so it is easy to scan despite its length; the length is justified by seven distinct patch fields. The final palette sentence partly restates the `color` schema description, which is the only sentence that does not fully earn its place.

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?

A nested-patch mutation tool with no annotations and no output schema, where the description supplies the missing safety and side-effect context (non-enforcement of WIP, display-only limits, sort-freeze behavior). Nothing an agent needs in order to call it correctly appears to be absent.

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 0%, so the description must compensate, and it documents every patch property: what `name` does, that null clears `color`, the wipLimit integer/null semantics, all nine sortMode values with their ordering meaning, onEnter's trigger condition and null-to-remove behavior, and the 1-1000 range of visibleCardLimit. This is meaning well beyond the raw enum lists in 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?

Opens with a specific verb+resource ("Patch a list (column)") and then enumerates exactly which settings can be patched, so an agent knows the scope without opening the schema. It also names the two siblings that own adjacent operations (kanbini_move_list, kanbini_archive_list), making it distinguishable from them.

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 routes two common confusions to alternatives: "To reorder lists use kanbini_move_list; to hide one use kanbini_archive_list." It also constrains the display fields with "Change them only when the user asks." It stops short of a general statement of when this tool should be chosen over kanbini_update_board or kanbini_update_card, but the field-level guidance is clear.

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