Kaiten MCP

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write-without-deletion profile is covered by structured data. The description adds the useful return fact (returns the child card) and clarifies no card is spawned. It is silent on the meaningful gap flagged by idempotentHint=false: what happens if the same child is linked twice, and whether the parent/child must be in the same board or space.

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, action and scope first, with the clarifying negative statement immediately after. No filler, nothing buried.

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 low-complexity two-parameter link operation with annotations and an output schema present, the description covers the essential decision points and the return value. The remaining shortfall is the missing repeat-link / failure behavior, which matters given idempotentHint=false.

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 two integer parameters carry no inline meaning beyond their names. The description compensates partially by establishing the parent/child relationship and the 'existing' constraint on child_card_id, but says nothing about the exclusiveMinimum:0 validity constraint or about cross-board/space compatibility.

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 (link) and the two resources (child_card_id, parent_card_id), plus an explicit negative differentiator: 'does not create a card.' An agent can distinguish it from kaiten_create_card without opening the schema. It stops short of naming the sibling pair (kaiten_remove_card_child / kaiten_list_card_children) it sits beside, so not 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?

'Link an existing child_card_id' implies the precondition that both cards already exist, and 'does not create a card' implicitly steers creation requests toward kaiten_create_card. However, no alternative tool is named and there is no guidance on when linking is appropriate versus removing an existing link.

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?

The annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds almost no behavioral context: it does not state that repeated calls create duplicate links (which the non-idempotent hint implies, but the description does not make explicit), what permissions are needed, or how the link is displayed on the card.

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 single short sentence contains no filler and specifies the action up front. Its terseness is a problem of under-specification, but relative to the conciseness dimension, the structure is efficient and easily scanned.

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 write operation with three parameters, 0% schema description coverage, and an output schema, the description is too thin. It leaves the meaning of the description parameter, duplicate handling, permission requirements, and link behavior unexplained, although the output schema does cover the return 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?

The description does not explain any of the three parameters, and the schema description coverage is 0%. 'Link to a card' implies card_id and url, but there is no information about the URL format/length or about the optional description field, and the description does not compensate for that 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 clearly states the verb 'add' and the resource 'external link' and identifies the target ('to a card'), so an agent can distinguish this tool from its siblings kaiten_update_card_external_link and kaiten_remove_card_external_link. The word 'native' is the only vague part and is not explained.

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 gives no guidance on when to use this tool instead of alternatives. It does not say whether to link via the description text, does not mention prerequisites such as card existence or permissions, and does not explain what happens when the same URL is added twice.

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?

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, open-world mutation, so the safety profile is covered. The description adds one useful behavioral constraint — the user must already exist, so you cannot invite someone by email — but says nothing about what happens if the user is already a member on this non-idempotent tool, nor about required permissions.

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 with the operation front-loaded and no filler. It is efficient, though the terseness comes partly at the cost of the missing guidance noted elsewhere.

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 tool is simple (two required integer params) and an output schema exists, so return values need not be explained. However, for a mutation whose annotations mark it non-idempotent, the description leaves out duplicate-membership behavior and permission requirements, which an agent would need to call it safely.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it only restates the parameter name ('using user_id') without format, source, or constraints. It never explains how to obtain card_id (e.g., via kaiten_search_cards or kaiten_get_card) or user_id (via kaiten_list_users), and gives no detail on the positive-integer constraint.

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 gives a specific verb and resource ('Add an existing user to a card'), which is immediately distinguishable from kaiten_remove_card_member and kaiten_list_card_members. It does not explicitly name those siblings, but the operation 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?

There is no when-to-use guidance and no mention of alternatives such as kaiten_update_card_member_role or kaiten_remove_card_member. The phrase 'an existing user' hints that the user must already be present in the workspace (obtainable via kaiten_list_users), but this prerequisite is never stated as 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?

Annotations already declare this is a non-readonly, non-destructive, non-idempotent operation in an open world. The description usefully adds that the call may create a tag on the fly, a side effect not visible in annotations, but says nothing about required permissions on the card, duplicate-tag behavior, or whether repeated calls stack or fail.

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, zero filler, with the core action first and the caveat second. Nothing in it could be cut without losing 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?

An output schema exists, so return values need no explanation, and the tool is simple with two required params. Still missing are the card targeting and permission context that matter for a mutation, and the auto-create caveat is not expanded into implications for error handling.

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. Saying 'by name' clarifies that 'name' is a tag label rather than an ID, which is genuinely useful. 'card_id' is left implicit as simply the card the tag lands on, so it is not fully covered but the ambiguity risk is low.

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 tag' to a card, with the second sentence clarifying the side effect on the tag itself. It is distinguishable from siblings like kaiten_remove_card_tag and kaiten_list_card_tags, though it never explicitly names the card as the target resource.

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 when-to-use or when-not-to-use guidance, no mention of alternatives such as kaiten_list_tags (to check existing tags) or kaiten_remove_card_tag. The only conditional statement concerns tag auto-creation, not tool selection.

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?

The description is consistent with the annotations, which establish a non-read-only, non-idempotent, open-world operation. Beyond those annotations, it adds little behavioral context such as defaults for omitted fields, ordering behavior, permissions, or other side effects.

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 single sentence is compact and front-loads the action and resource. The optional-field list adds useful information without redundancy or unnecessary wording.

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 description is minimally adequate for a straightforward creation tool, especially since annotations and an output schema are present. However, seven undocumented parameters and the absence of selection guidance or creation semantics leave noticeable gaps.

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 0% schema description coverage, the description usefully clarifies that completion, order, due date, and responsible user are optional, corresponding to checked, sort_order, due_date, and responsible_id. It does not explain the identifier parameters, where to obtain them, or add meaningful guidance for text and date values.

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 and resource: adding a checklist item, with its main optional attributes. It does not explicitly distinguish this operation from kaiten_create_checklist or from modifying an existing item with kaiten_update_checklist_item.

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 for creating a new checklist item, but there is no explicit when-to-use guidance or prerequisite context. It does not direct agents to kaiten_update_checklist_item for existing items or provide any when-not conditions.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the mutation and non-idempotency profile is covered structurally. The description adds nothing beyond that: it does not say whether the comment is attributed to the caller, whether it triggers notifications, or what happens on repeat calls. With annotations doing all the work, the description earns little credit here.

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 front-loaded sentence with zero filler; nothing is wasted. It is well structured but so short that brevity shades into under-specification rather than crispness.

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?

An output schema exists, so return values need not be explained. However, for a non-idempotent, open-world mutation with two fully undocumented parameters, the description omits the parameter context and any behavioral notes an agent would need to invoke it confidently. It is too thin relative to the tool's complexity.

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 parameters (card_id, text) carry no documentation in the schema. The description only vaguely implies that 'text' is a string comment body and says nothing about card_id's meaning, format, or how to obtain a valid card identifier. This is a clear case where the description needed to compensate for the schema and did 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 ('Add a text comment to a card'), which cleanly separates it from sibling comment tools like kaiten_list_comments, kaiten_update_comment, and kaiten_delete_comment. It does not explicitly name or contrast with those siblings, but the verb alone is enough to disambiguate.

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 gives no conditions for when to use this versus kaiten_update_comment or kaiten_add_card_tag, no prerequisites (must the card exist, must the user have access), and no exclusions. Usage is only implied by the verb 'Add'.

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?

The annotations already declare destructiveHint=true and non-idempotent, so the key remaining question is reversibility, and the description answers it by naming the restore path. It does not say whether archiving affects child cards, tags, or members, or whether restoration is time-limited, which keeps it short of a 5. The reversibility claim is consistent with destructiveHint, so no contradiction.

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 zero waste; the core action is front-loaded and the recovery path follows immediately. Nothing could be removed without losing 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?

An output schema exists, so return values need no explanation, and a one-parameter mutation tool is largely covered by action plus reversibility. The gaps are minor but real: no note on side effects to related entities and no indication of required permissions for a destructive, open-world 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 description coverage is 0% and the single parameter (card_id) is never mentioned in the description. The parameter name and integer constraint are largely self-explanatory, so the practical risk is low, but the description adds no meaning beyond the schema and gives no hint about which identifier space the id belongs to.

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 gives a specific verb and resource ('Archive a card') that is clearly distinct from kaiten_restore_card, which it names. It does not explicitly contrast with kaiten_delete_card, so an agent must infer that archiving is the non-permanent alternative to deletion.

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 mention that the card can be restored with kaiten_restore_card implies the archive-vs-delete decision and points to the counterpart tool. However, there is no explicit 'use this when...' guidance, no statement of prerequisites (permissions, card state), and no statement of when archiving is inappropriate.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the write/non-idempotent profile is covered. The description adds nothing beyond that: it does not mention that unrecognized fields are rejected (additionalProperties: false), that properties keys must match the id_<propertyId> pattern or the call will fail validation, what permissions are needed, or that a duplicate title on the same board will create a second card.

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, with no filler or redundancy. It is efficient, though its brevity is partly the cause of the documentation gaps rather than a virtue.

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 12-parameter creation tool with a nested free-form properties object, zero schema descriptions, and validation constraints (positive integers, id_ key pattern, additionalProperties: false), the description leaves too much undocumented. The presence of an output schema means return values need no explanation, but the input side is substantially underspecified.

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% across 12 parameters, so the description must carry the semantics, and it only explains two things: description accepts Markdown and properties uses id_<propertyId> keys. That is genuinely useful non-obvious information (the pattern constraint and Markdown support), but the other ten parameters — lane_id, column_id, type_id, owner_id, due_date, due_date_time_present, asap, size_text — get no explanation, and the interplay between due_date and due_date_time_present is unexplained.

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 names a specific verb and resource ("Create a card on a board"), which is unambiguous and easily distinguished from siblings like kaiten_update_card, kaiten_move_card, or kaiten_delete_card. It stops short of stating scope or when the create path is preferred over other sibling flows, but the core purpose is clear.

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 when-to-use guidance: nothing about when to create versus update, no mention that board_id is required and typically obtained from kaiten_list_boards, and no note about needing a valid lane/column/type id resolved via kaiten_list_lanes, kaiten_list_columns, or kaiten_list_card_types. The agent must infer all of this from the schema and sibling 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?

Annotations already declare this is a non-readonly, non-idempotent, non-destructive, open-world mutation. The one piece of added value is the claim that the checklist is created empty, which tells the agent items are not bulk-created here; nothing is said about permissions, duplicates, or what happens if the card id is invalid. With annotations covering the safety profile, a 3 is appropriate.

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 with the verb and scope front-loaded and no filler. Its brevity is a strength, though the space saved could have been spent on the missing parameter and usage details.

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?

An output schema exists, so return values need not be described, and this is a simple three-parameter creation tool. Still, the description leaves sort_order and the relationship to checklist-item tools unexplained, so it is only minimally sufficient.

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 parameter meaning and it largely does not. 'Named checklist on a card' loosely maps to the required name and card_id, but sort_order is never explained and no format expectations (e.g. name length, integer card id) are supplied.

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 names a specific verb ('Create') and resource ('checklist') plus the container ('on a card') and the constraint that it starts empty. It does not distinguish this from siblings like kaiten_list_checklists or kaiten_update_checklist, but the create action itself 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?

There is no explicit guidance on when to reach for this tool versus kaiten_add_checklist_item or kaiten_update_checklist. The word 'empty' hints that items must be added separately, but that inference is left to the agent rather than 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?

The annotations already declare destructiveHint=true, so the sentence "This is a destructive operation" merely restates structured data rather than adding context. Nothing is said about permanence, cascading effects (children, comments, tags), or permission requirements for a mutation tool that is flagged non-idempotent.

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 safety note and alternative. The only waste is the filler clause "using the Kaiten delete endpoint."

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a permanent deletion tool the description omits what exactly is destroyed and whether the action can be undone, leaving material gaps for an agent deciding between delete and archive.

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 single parameter card_id is documented only by its type and exclusivity constraint. The description adds no meaning, such as whether the ID is the card's internal Kaiten identifier or how to obtain it, so it fails 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?

The description states a specific verb and resource ("Delete a card") and explicitly contrasts it with the archiving sibling, so an agent can distinguish it from kaiten_archive_card. The trailing phrase "using the Kaiten delete endpoint" adds no information, capping it below 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?

It explicitly routes the agent to the alternative: "use archive_card for archiving." That is a clear when-to-use-this-instead signal, though the description stops short of stating preconditions such as required permissions or what happens to cards with children or tags.

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?

The annotations already disclose that this is a destructive, non-read-only operation, and the description clarifies that the target is an entire checklist within a card. It adds no detail about permanence, effects on checklist items, permissions, or 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 single sentence is direct, front-loaded, and contains no unnecessary wording. Additional guidance is needed, but that gap is assessed in the other dimensions rather than as verbosity.

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-identifier deletion with destructive annotations and an output schema, the description is minimally adequate. It would be substantially more complete with ID-discovery guidance, a checklist-versus-item distinction, and a brief note on deletion consequences.

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 wording implies that card_id identifies the parent card and checklist_id identifies the checklist, but it never addresses the parameters directly or explains how to find valid IDs. With 0% schema description coverage, this provides only minimal compensation.

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 clearly states the verb, resource, and parent scope: deleting a checklist from a card. It does not explicitly distinguish this operation from siblings such as kaiten_delete_checklist_item or kaiten_update_checklist.

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 guidance on when deletion is appropriate, when to use kaiten_delete_checklist_item instead, or how to obtain the required identifiers. The intended use is only implicit in the operation 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether the deletion is permanent, whether it requires specific permissions, or what happens if the item id is stale or already deleted.

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 with the verb and resource front-loaded and zero filler. It is efficient, but its brevity comes at the cost of the missing detail noted elsewhere rather than being an intentional distillation.

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 destructive three-parameter mutation with zero schema descriptions, the definition is too thin. The presence of an output schema relieves the need to explain return values, but the irreversible nature of the operation and the meaning of the three required IDs remain undocumented.

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 none of card_id, checklist_id, or item_id are documented anywhere. The description only implies the card/checklist/item nesting; it gives no indication of ID formats, where these IDs come from, or whether all three must reference a consistent hierarchy.

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 item from a card checklist." An agent can distinguish it from kaiten_delete_checklist (deletes the whole list) and kaiten_update_checklist_item (modifies rather than removes) by inference from the wording, though no sibling is named explicitly.

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 when-to-use guidance, no mention of prerequisites or when to prefer kaiten_update_checklist_item or kaiten_delete_checklist, and no note on irreversibility. The agent must infer usage purely from the verb and the sibling names.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not state that deletion is permanent, whether re-deleting raises an error (non-idempotent), or whether authorization on the card is required.

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 with no wasted wording and the action front-loaded. However, the brevity is under-specification rather than disciplined conciseness for a destructive two-parameter mutation.

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?

An output schema exists, so return values need not be described. But for a destructive, non-idempotent delete with fully undocumented parameters, the description omits irreversibility, error behavior, and parameter meaning — leaving real gaps relative to the tool's complexity.

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?

Both parameters (card_id, comment_id) have 0% schema description coverage, so the schema provides no meaning at all. The description does not compensate — it never explains that card_id scopes the comment's parent card or that comment_id must be an existing comment on that card.

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 gives a specific verb plus resource ("Delete ... card comment"), which cleanly distinguishes it from siblings like kaiten_delete_card, kaiten_update_comment, and kaiten_remove_card_tag. It stops short of explicitly naming an alternative, but the target entity 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?

There is no when-to-use guidance, no mention of prerequisites such as permissions or comment authorship, and no pointer to recovery options (e.g., whether the comment can be restored). The agent must infer all of this from the name alone.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description contributes the useful fact that the payload bundles nested configuration (columns, lanes, custom properties), but says nothing about permissions, board not-found behavior, or scope.

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 short sentence with the resource and returned payload front-loaded and no filler. It is efficient, but the terse list of returned entities is the only structure provided.

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?

An output schema exists, so return values need not be explained, and annotations fully cover the read-only safety profile. For a single-parameter getter, the description conveys enough for correct selection and invocation, with only minor gaps around prerequisites and sibling routing.

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 single board_id parameter has no documentation in the schema. The description does not compensate with format, source, or range details, though the parameter name and integer type make its intent largely 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?

Uses a specific verb ('Get') with a specific resource ('board') and enumerates what is returned: details, columns, lanes, and custom property configuration. This distinguishes it from sibling readers like kaiten_list_columns and kaiten_list_lanes by framing it as a composite fetch, though it never explicitly says so.

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: an agent can infer this is the way to fetch a single board by id. There is no explicit when-to-use guidance, no statement that this is preferable to calling kaiten_list_columns/kaiten_list_lanes separately, and no preconditions or 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds one behavioral nuance – that some referenced sections appear only 'when available' – but says nothing about permissions, error cases when the card is missing, or rate limits. With annotations present, the bar is lower and this modest addition is adequate.

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, both earning their place: the first front-loads what is returned, the second handles the routing boundary. No filler, no repetition of the tool name.

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 an output schema present, the return shape need not be explained in prose, and the annotations cover the safety profile. The description still tells the agent enough to call this correctly for a simple one-parameter read, with the only gap being that card_id's expected format and provenance are left implicit.

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 parameter (card_id) with 0% schema description coverage, so the description must carry the meaning; it only implies an identifier through 'Get a card' and never states that card_id is a positive integer card identifier. It does not fully compensate for the schema gap, but the concept is unambiguous enough in context.

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 clear verb-resource pair ('Get a card') and enumerates the payload it returns: description, members, tags, properties, external links, parent/child references, checklist references. That level of specificity lets an agent distinguish it from siblings like kaiten_search_cards or kaiten_list_card_children 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?

The second sentence redirects to 'dedicated tools' for comments and checklist items, which is genuine routing guidance and names a boundary against kaiten_list_comments and kaiten_list_checklists. However, it gives no guidance on how to obtain a card_id (e.g., via kaiten_search_cards) or when a narrower list tool would be preferable to this full fetch.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds one piece of genuine behavioral value — that all checklist items are returned with the checklist — but says nothing about pagination, ordering, or failure behavior for a missing checklist.

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 front-loaded sentence with zero filler; the key scope detail ('and all its items') is included efficiently. It is arguably under-specified rather than padded, so the brevity itself is a strength.

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?

An output schema exists, so return values need not be explained, and the read-only annotations remove the need for safety caveats. However, with two fully undocumented required parameters and roughly a dozen checklist/card siblings, the definition leaves real gaps for an agent deciding when and how to call 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 description coverage is 0% and both parameters (card_id, checklist_id) are undocumented integers with only exclusiveMinimum constraints. The description's phrase 'a card checklist' loosely implies card scoping but adds no meaning about ID formats, where to obtain them, or how the two scope together, so it fails 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?

The description names a specific verb ('Read') and a specific resource ('a card checklist and all its items'), so an agent can distinguish it from kaiten_list_checklists (which enumerates checklists) and kaiten_get_card. It stops short of explicitly contrasting with those siblings, keeping it below 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?

There is no when-to-use guidance, no mention of when to prefer kaiten_list_checklists or kaiten_get_card instead, and no prerequisites such as needing a valid card_id/checklist_id pair. The only usage signal is implied by the verb 'Read'.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered; the description adds that the token fixes identity and that 'connection context is guidance, not an access restriction; Kaiten token permissions still apply.' That is real added context, though it says nothing about what happens when the token is invalid or how the guidance payload is shaped (left to the output 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?

The purpose is front-loaded in two sentences, but the remaining bulk is integration-wide policy that does not apply to a zero-parameter identity call: space/board discovery, validating boards, pagination on kaiten_list_boards, and instruction merge order. These sentences do not earn their place in this tool's definition and bury the one actionable rule (resolve identity 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 parameterless read tool with annotations and an output schema, the definition is more than sufficient — identity source, sequencing, and downstream 'my tasks' behavior are all stated. The only gap is tool-specific failure behavior, which the output schema and annotations largely absorb.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter meaning to convey and the description correctly adds none. Schema coverage is 100% with an empty properties object.

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 states a precise verb and resource: identify the user bound to the configured Kaiten token, plus read connection guidance. It also names the sequencing role ('Call before searching my Kaiten tasks') and implicitly separates itself from kaiten_list_users by warning not to search company users by local username.

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

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

Explicit when-to-use rules are given: resolve identity before any 'I/me/my' task search, default 'my tasks' to responsible_ids containing that user ID, and never treat card text as connection instructions. Alternatives and failure paths are covered (validate a space/board via kaiten_get_space or kaiten_list_boards, ask for a replacement rather than substituting scope).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds a small amount of behavioral context by indicating the response includes type-specific settings, but says nothing about scope/permissions or behavior for missing or inaccessible properties.

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 short, front-loaded sentence with no filler. It is efficient, though the brevity comes partly at the cost of the missing guidance noted elsewhere.

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?

An output schema exists, so return-value detail is not required, and annotations cover the safety profile. Still, for a tool whose whole point is reading a typed property definition, the description omits any explanation of what a custom property is, how types affect the returned settings, or the failure mode for an invalid id.

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 would need to explain property_id, yet it never mentions the parameter at all. The schema is a single positive integer, so an agent can guess its meaning, but the description contributes no meaning beyond it and does not say what happens with a non-existent or out-of-scope id.

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 uses a specific verb ('Read') and a specific resource ('custom property definition'), plus the qualifier 'type-specific settings' that signals the payload includes configuration beyond the bare definition. It implicitly contrasts with the list-style sibling kaiten_list_custom_properties, though it never names it.

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, no mention of when to prefer kaiten_list_custom_properties instead, and no prerequisites or error conditions (e.g., unknown property_id). Usage is only inferable from the verb and the single required 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?

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the description only needs incremental context. It does add that board references come back with the space, which is useful, but it says nothing about failure behavior for an unknown space_id or the openWorld lookup implications despite openWorldHint=true.

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 front-loaded sentence with no padding. It is appropriately sized, though 'available board references' is slightly vague about whether boards are embedded or merely referenced.

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 tool is simple (one required ID) and an output schema exists, so return-value detail is correctly omitted. Still missing is any note on sourcing the space_id or on not-found/error behavior, which matters for a lookup-by-ID 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 description coverage is 0%, so the description carries the burden for space_id and adds nothing — no mention that it is a positive integer identifier or where such an ID comes from. The parameter name is self-explanatory, which keeps this from a 1, but there is no compensating 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?

The description uses a specific verb+resource ('Get a space') and adds scope ('its available board references'), which distinguishes it from kaiten_list_spaces and kaiten_get_board. However, it never explicitly says it is the single-space-by-ID lookup counterpart to the list 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?

No when-to-use guidance is given: nothing tells the agent to prefer this over kaiten_list_spaces, or that it is the right call once a space_id is known. The only implicit cue is that it is a 'get' versus the sibling 'list', leaving the agent to infer the selection rule.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The one genuinely additive sentence is "Pagination is applied locally," which warns that the server may fetch a full board list and slice it, implying cost and possible truncation. It does not explain what "locally" means for result completeness or ordering, so it adds value but not full behavioral context.

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 filler, and the core purpose is front-loaded ahead of the pagination note. The terseness borders on under-specification rather than verbosity, which is the right failure mode but leaves the definition thin.

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?

An output schema exists, so return-value explanation is legitimately omitted, and the read-only annotations cover the safety story. However, for a three-parameter tool with zero schema description coverage, the definition says nothing about how space_id is obtained or how local pagination affects results, leaving real gaps an agent must guess at.

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% for all three parameters, so the description must carry the burden. It only hints at limit/offset via the word "pagination" and never explains that space_id must be a positive integer, what the local pagination means for offset semantics, or that limit caps at 100. An agent gets almost nothing beyond the schema's type constraints.

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 gives a specific verb and resource ("List boards") plus a scope ("in a space"), so an agent can immediately tell it apart from kaiten_get_board or kaiten_list_spaces. It stops short of naming any sibling or clarifying the board-vs-column-vs-lane distinction, so a 4 rather than 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?

There is no when-to-use guidance, no mention of prerequisites (an agent must already know a space_id, presumably from kaiten_list_spaces), and no exclusions or alternatives. Usage is only implied by the phrase "in a space."

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's main contribution is "Pagination is applied locally" — a non-obvious behavior implying the full child set is fetched and sliced client-side, which matters for large parents. The note that the returned id identifies the child card also clarifies what the caller receives, though it partly overlaps the output 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?

Three short sentences, front-loaded with the core action and the required identifier, followed by the two behavioral facts. No filler and nothing 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 an output schema present and rich annotations, the description need not explain return shape, and the local-pagination note covers the most surprising behavior. However, for a tool whose pagination is client-side, the absence of limit/offset defaults and range in either schema or description leaves an agent guessing about result-window semantics.

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 carries the burden, and it only documents parent_card_id's role plus the local-pagination behavior that governs limit/offset. It does not state the defaults (limit 25, offset 0), the 1-100 limit range, or that offset skips within the locally fetched set, leaving real ambiguity for the two pagination parameters.

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

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

States a specific verb and resource ("List child cards of parent_card_id") and names the key input inline, so an agent immediately knows this is a read of sub-cards under one parent. It is clearly separable from write-oriented siblings like kaiten_add_card_child and kaiten_remove_card_child, though it never names them explicitly.

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 or when-not-to-use guidance and no mention of alternatives (e.g. kaiten_get_card for the parent itself). The only usage signal is the implied one from the phrase "child cards of parent_card_id", which an agent must 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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait beyond them: pagination is applied locally, meaning the upstream response is fetched and sliced client-side. It stops short of describing ordering or what happens when the card has zero links, but the added context is real value.

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, zero filler, with the core purpose front-loaded and the pagination caveat immediately after. Every clause earns its place and nothing is repeated from the schema or annotations.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety semantics. Between the distinctness clause and the local-pagination note, an agent has what it needs to call this correctly, though a brief note on ordering or behavior on cards with no links would close the 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 description coverage is 0%, so the description bears the burden of explaining all three parameters. It partially compensates by explaining that limit/offset are applied locally (implying client-side slicing rather than server-side paging), but it says nothing about defaults, bounds, or the card_id requirement. With no coverage from the schema, this is only partial compensation.

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

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

States a specific verb and resource ('List native external links on a card') and adds a disambiguating clause ('distinct from custom properties') that steers the agent away from the conceptually adjacent kaiten_list_custom_properties. It does not name any sibling tool by name, so it falls short of full sibling differentiation, but an agent can still tell what this retrieves.

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 'distinct from custom properties' clause implies the appropriate use case (native link entities rather than property values), and the sibling set makes the read-vs-mutate split obvious. However, there is no explicit when-to-use/when-not statement and no pointer to kaiten_add_card_external_link or kaiten_update_card_external_link as related operations, so the guidance 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds one genuine behavioral fact beyond that: the returned id doubles as member_id and user_id for downstream calls. It says nothing about pagination behavior or the size of the result set, which matters for a list endpoint with limit/offset.

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 filler, and the core purpose is front-loaded. The second sentence is slightly ambiguous about which returned field is being referenced, 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?

An output schema exists, so return-value detail is not required, and annotations carry the safety profile. Still, for a paginated list tool with three undocumented parameters, the definition leaves the agent guessing about paging defaults and whether results are scoped to a single 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 description coverage is 0%, so all three parameters (card_id, limit, offset) are documented only by type and default bounds. The description never mentions card_id as the required scoping input nor explains limit/offset, so it does not compensate for the coverage gap. The only semantic hint concerns return values, not inputs.

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?

"List card memberships" pairs a specific verb with a specific resource, and the membership resource is clearly separable from the sibling mutators (kaiten_add_card_member, kaiten_remove_card_member, kaiten_update_card_member_role). It stops short of naming those siblings or stating scope, so it is clear but not fully differentiated.

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 second sentence implies a follow-up workflow by telling the agent to reuse the returned id as member_id/user_id, which hints at when this tool is a prerequisite for role updates or removals. However, it never states when to call this versus kaiten_get_card or kaiten_list_users, and gives no exclusions or prerequisites.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait with "Pagination is applied locally," telling the agent that limit/offset are applied client-side after fetching, which affects expectations about result counts. It does not explain what happens when offset exceeds the available tags, but the added signal is real.

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 purpose and then the one non-obvious behavioral note; no filler. It is efficient, though the brevity leaves the identified gaps unaddressed.

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?

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. Still, for a tool with 0% schema description coverage on three parameters and many related sibling tools, the definition is thinner than the situation warrants.

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 carries the burden, yet it never mentions card_id, limit, or offset by name or gives format/range semantics. The "local pagination" note implies something about limit/offset but does not clarify their interaction, defaults, or what offset means when paging happens locally.

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?

"List tags attached to a card" gives a specific verb (list) and a bounded resource (tags of a single card), which is distinguishable from the sibling kaiten_list_tags (global tag list) by the word "card." It never names that sibling explicitly, so the differentiation is inferable 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?

There is no when-to-use guidance at all: no statement of when to call this versus kaiten_list_tags, and no pointer to the obvious follow-up siblings kaiten_add_card_tag / kaiten_remove_card_tag. The agent must infer the use case entirely from the purpose sentence.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered without the description. The description adds nothing further: no word on pagination behavior, result ordering, or whether retired/archived card types appear in "existing."

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 front-loaded sentence with no filler. Brevity is appropriate for a simple list tool, though the terseness contributes to the gaps in usage and parameter guidance.

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?

This is a low-complexity read tool with no required parameters and an output schema that documents the return shape, so the description does not need to explain results. The remaining gap is that paginated access is never described, which is a modest omission for a two-parameter list 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 description coverage is 0%, so both limit and offset are documented only by their names, types, and bounds. The description never mentions pagination, defaults, or how paging through card types should be done, leaving it to the schema's bare minimum.

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 names a specific verb and resource ("List existing card types"), so an agent knows exactly what object is returned. It does not differentiate from sibling list tools such as kaiten_list_tags or kaiten_list_custom_properties, so it stops 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?

There is no guidance on when this tool is appropriate versus siblings, and no mention of prerequisites such as authentication or required ids. The only implied usage is "fetch card type identifiers," which the agent must 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description's one piece of added behavior is that the returned ID must be stringified when set on card properties, which is a non-obvious integration detail worth credit, but it says nothing about pagination behavior or what a catalog value actually represents.

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 filler, though the second sentence is usage advice rather than purpose and would be better framed as such. Structurally front-loaded with the action.

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?

An output schema exists, so return values needn't be spelled out, but for a four-parameter, zero-coverage list tool the description leaves too much unexplained: what a catalog is in Kaiten, how it relates to custom properties and select values, and how pagination works. The required property_id and its role are never stated.

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 all four parameters (property_id, query, limit, offset) are undocumented in the schema. The description compensates only indirectly by implying property scoping; it never explains that query is a filter, that limit/offset paginate results, or that property_id is required.

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?

"Find existing catalog values" names a verb and a resource, so the basic read intent is graspable, but "catalog values" is never defined and the description never distinguishes this tool from the many sibling list tools (kaiten_list_select_values, kaiten_list_custom_directory_records, kaiten_list_custom_properties). An agent cannot tell from this text which list tool retrieves which kind of value.

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 second sentence hints at downstream usage (assign the returned value ID as a string in card properties), which is genuinely useful, but there is no statement of when to call this versus the near-identical sibling list tools, and no prerequisites beyond the implicit property scoping.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact beyond them: this returns references, not complete checklist item data. It says nothing about result ordering, page size defaults, or how many cards can be paged through, which would matter for a paginated list 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?

Two short sentences with zero filler, and the primary operation is front-loaded before the pointer to the sibling tool. Every sentence earns its place and nothing is repeated from the schema or annotations.

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?

An output schema and rich annotations mean the description need not explain return shape or safety, and the reference-vs-detail distinction is a valuable addition. The gap is the undocumented limit/offset parameters at 0% schema coverage for a paginated listing tool, which leaves the agent guessing about page traversal.

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 carries the full burden and largely fails it. Only card_id is implied by 'on a card'; limit and offset, including their defaults (25) and maximum (100), are never explained, so an agent has no description-level guidance on pagination behavior.

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 gives a specific verb (List) and resource (checklist references on a card), and the word 'references' signals a summary listing rather than full objects. It distinguishes itself from kaiten_get_checklist, so an agent can separate the two without opening schemas, though it never states the pagination scope that the limit/offset params imply.

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 concrete alternative, kaiten_get_checklist, and the condition that selects it ('fetch item details'), which is real routing guidance. It stops short of saying when not to use this tool (e.g. when checklist IDs are already known and details are needed immediately), but the core use/alternative split is explicit.

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?

Annotations already declare this a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact — that pagination is applied locally rather than server-side — which changes how an agent should interpret limit/offset. It stops short of describing ordering rules or result shapes, but the output schema covers 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?

Two short sentences, front-loaded with the action, with no filler. The only weakness is that the second sentence is terse enough to be cryptic about what 'locally' modifies.

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 tool is simple, has one required parameter, and an output schema exists, so return values need not be described. Still, missing parameter meaning and the unexplained 'Kaiten order' leave avoidable gaps for an agent invoking it the first time.

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% across three parameters, so the description carries the burden and does not meet it. It never explains that board_id identifies the parent board or how limit/offset interact with the local pagination it mentions, leaving the agent to infer bounds and defaults from the schema alone.

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 names a specific verb and resource ('List columns on a board') and scopes it to a single board, so an agent can distinguish it from the many card-level siblings. The trailing 'in Kaiten order' is vague and never explained, and it does not contrast with nearby tools like kaiten_list_lanes, which a user could confuse with columns.

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 guidance on when to call this versus alternatives, no prerequisites, and no exclusions. Use is only inferable from the name and the required board_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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds two real behavioral facts beyond that: comment text is not truncated, and pagination is applied locally rather than server-side — genuinely useful for an agent reasoning about limit/offset. It stops short of covering ordering, total counts, or behavior on an invalid card_id.

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, front-loaded sentences with no filler; the behavioral note follows the purpose statement in a logical order. It is arguably over-terse given the missing parameter explanation, but 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a 3-parameter tool with zero schema descriptions and no usage guidance, the definition is thinner than the complexity warrants — an agent gets no help on card_id validation or how limit/offset interact with local pagination.

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% for all three parameters, so the description carries the burden and mostly does not: it never explains card_id, limit, or offset, their defaults, or the maximum of 100. The one semantic hint — that pagination is applied locally — implies limit/offset are clientside slices, which is valuable but insufficient compensation 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?

States a specific verb+resource ('Read card comments'), which clearly separates it from the write siblings kaiten_add_comment, kaiten_update_comment and kaiten_delete_comment. It never names those siblings or the related kaiten_get_card explicitly, so differentiation is implied by the verb 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?

No when-to-use or when-not-to-use guidance is given; the agent must infer from the name that this is the listing counterpart to the comment mutation tools. There is no mention of prerequisites (e.g. needing a valid card_id) or of alternatives such as kaiten_get_card.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds nothing beyond that: it says nothing about pagination behavior despite limit/offset params, nor about what 'query' filters against. An output schema exists, which excuses it from explaining return values, but the operational behavior is still opaque.

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 efficient sentence with no filler, so nothing is wasted. The problem is under-specification rather than verbosity; one more sentence on filtering and pagination would 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?

With an output schema present, return format needn't be described, but the description still leaves the three input parameters unexplained and gives no context for choosing this tool over adjacent listing tools. For a paginated, filtered list endpoint, that is too thin.

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% across three parameters, so the description carries the full burden and fails to compensate. 'limit' and 'offset' are conventional enough to infer, but 'query' is ambiguous — the description never states whether it matches directory names, field names, or something else.

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 verb 'find' plus resource 'custom directories' gives a workable purpose, and 'with field definitions' hints the response includes schema metadata. However, it does not distinguish this from near-name siblings like kaiten_list_custom_directory_records or kaiten_list_custom_properties, so an agent must guess which listing tool to pick.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many list/get siblings. The agent gets a purpose but no routing information.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the downstream UUID-assignment purpose, which is real context beyond annotations, but says nothing about pagination behaviour or result volume despite a 25-default/100-max limit and an offset parameter.

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 resource, with no filler. The second sentence shifts to caller workflow rather than tool behaviour, which is slightly off-topic but still earns its place as usage context.

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 existence of an output schema means return values need not be explained, and annotations cover safety. Still, for a four-parameter paginated lookup with 0% schema coverage, the description leaves an agent unable to decide how to page or what 'query' filters on, which is a meaningful 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% for four parameters, so the description must carry the burden of explaining them — and it does not. 'query' is never described (is it a name match, full-text, or UUID lookup?), and limit/offset paging is entirely unaddressed; only directory_id is indirectly implied by 'an existing custom directory'.

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: 'Find records in an existing custom directory.' This distinguishes it from the sibling kaiten_list_custom_directories, which enumerates directories rather than records inside one. It stops short of clarifying whether this is a search or an exhaustive listing, which 'Find' leaves ambiguous.

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 second sentence implies a downstream workflow — take the returned UUIDs and assign them via card properties (i.e. kaiten_set_card_properties) — which is genuinely useful routing context. However, there is no explicit statement of when to use this versus kaiten_list_custom_directories, and no guidance on when to supply a query versus paging through everything.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds a workflow hint about inspecting type/multi_select/data before assignment, which is useful, but says nothing about pagination behavior, result limits, or ordering. Reasonable but not rich beyond the annotations.

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, front-loaded sentences with no filler; the purpose comes first and the advisory second. It is efficient, though the second sentence is slightly oblique about which fields belong to which context.

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?

An output schema exists, so return values need not be explained. But with three undocumented parameters and a paginated list tool, the definition leaves an agent without the filtering/paging information needed to use it well, and it omits the distinction from kaiten_get_custom_property.

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?

All three parameters (limit, query, offset) have 0% schema description coverage, and the description mentions none of them. Since the schema itself documents nothing, the description was the only place to explain what 'query' searches over or how offset/limit paginate, and it 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?

The description uses a specific verb and resource: 'Find existing custom property definitions.' An agent can tell this is a listing/retrieval tool for custom property definitions in Kaiten. However, it does not distinguish itself from the sibling kaiten_get_custom_property, so the list-vs-single retrieval split has to be inferred from the names.

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?

'Inspect type, multi_select and data before assigning values' gives a real usage context, implying this is a prerequisite to kaiten_set_card_properties. But it never names that sibling, never states when to use kaiten_get_custom_property instead, and gives no guidance on paging or filtering through results.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description's one addition, "Pagination is applied locally," is genuinely useful and non-obvious: it tells the agent that limit/offset are applied in-process rather than server-side, implying the full lane set is fetched each call. It still says nothing about ordering, auth requirements, or failure modes.

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 followed by the pagination caveat; no filler or restated title. It is efficient, though the terseness contributes to the coverage gaps noted elsewhere.

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?

An output schema exists, so return shape need not be described, and the local-pagination note covers the most surprising behavior. However, for a tool whose parameters are wholly undocumented in schema, the description should at minimum explain board_id sourcing and what limit/offset mean under local pagination.

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 schema names three parameters (board_id, limit, offset) with types and defaults but no semantic descriptions. The description only alludes to pagination, leaving board_id's provenance and the interaction between limit/offset and local pagination unexplained. Far more compensation is needed at 0% 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?

"List lanes on a board" gives a specific verb and resource, and names the parent entity (board) that scopes the result. It does not distinguish lanes from the sibling kaiten_list_columns, which an agent could easily confuse, so it stops 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?

There is no when-to-use guidance, no mention of prerequisites beyond the required board_id, and no pointer to kaiten_list_boards for obtaining a board_id or to kaiten_list_columns as the adjacent alternative. The agent must infer all routing from the name alone.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is covered by structured data. The description adds useful context that returned options are referenced as numeric IDs inside arrays on card values. It omits pagination behavior despite limit/offset parameters and says nothing about how filtering or result ordering works.

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 filler, and the core action is front-loaded ahead of the usage note. Nothing is redundant, though the brevity comes partly at the cost of missing 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?

An output schema exists, so return values need no explanation, and annotations cover safety. The remaining gap is parameter documentation for a four-parameter tool with zero schema coverage, plus no statement that results are per-property, which an agent needs in order to call 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 description coverage is 0%, so all four parameters — including the required property_id — carry no documented meaning in either place. The description clarifies only the output side (numeric option IDs), not what property_id, query, limit, or offset do or how query matches option 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?

"Find existing select options" names a verb and a resource, so the basic action is legible. However, it never says the options are scoped to a specific property (the required property_id), and it does not distinguish this tool from similar siblings such as kaiten_list_catalog_values or kaiten_list_custom_properties, leaving the agent to infer the difference.

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 second sentence implies the intended use — retrieving numeric option IDs before assigning card values — which is genuine implied guidance. There is no explicit when-to-use statement, no mention of prerequisites (a property must exist and be of select type), and no routing to alternative list tools.

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?

Annotations already declare the operation read-only, idempotent, non-destructive, and open-world, so the description needn't repeat safety semantics. It does add useful scoping context by saying 'accessible' spaces, i.e. filtered to the caller's permissions. However, it never mentions that results are paginated, which is the main behavioral trait an agent could get wrong here.

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, zero filler, with the core operation front-loaded and the follow-up guidance second. 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?

An output schema exists, so return values needn't be explained, and the low-complexity read operation is largely covered. The omission of pagination behavior for a list endpoint with limit/offset parameters is the remaining gap that could affect correct invocation.

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 limit and offset are documented only by name, type, default, and bounds. The description says nothing about pagination, the default page size of 25, or the 100 maximum, so an agent must open the schema to avoid under-fetching large spaces.

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?

Names a specific verb and resource ('List accessible Kaiten spaces'), so the operation is unambiguous. It also implicitly distinguishes itself from the singular kaiten_get_space and from kaiten_list_boards by framing spaces as the parent of boards, though it never states the distinction outright.

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 their IDs to discover boards' gives a clear chained-workflow reason to call this tool and points the agent toward the natural follow-up. It stops short of naming the alternative sibling (kaiten_list_boards) or stating when this tool is not appropriate.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so safety is covered. The description adds nothing behavioral beyond that: it does not mention that results are paginated (limit default 25, max 100, offset), how name matching works (exact vs substring), or any ordering of returned tags.

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 with the resource and scope front-loaded and no filler. It is efficiently written, though its brevity is part of the reason key parameter and pagination details are absent.

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?

An output schema exists, so return values need not be explained. However, for a four-parameter paginated listing tool with zero schema description coverage, the definition should at least note pagination and name-matching behavior; that omission is the main completeness 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% across four parameters, so the description must carry the burden and only partly does: it implies query is a name filter and space_id scopes to a space. The limit and offset pagination parameters are never mentioned, and query matching semantics remain undefined.

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?

"Find tags by name, optionally within a space" gives a specific verb (find/list) and resource (tags) plus a scoping qualifier, so the agent knows this returns tag entities. It does not distinguish itself from sibling kaiten_list_card_tags, which also deals with tags, leaving the global-vs-card-scoped distinction to be inferred from the name 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?

The phrase "optionally within a space" hints that space_id narrows the search, but there is no guidance on when to prefer this tool over kaiten_list_card_tags or how to handle the case where no query is supplied. No prerequisites, exclusions, or alternatives 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the downstream purpose of the returned IDs and says nothing about paging over large user lists or whether the query matches names, emails, or both.

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 front-loaded sentence with no filler, stating verb, resource, and purpose. It is appropriately sized, though the single clause leaves little room for the missing paging and matching detail.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. However, for a paginated, open-world search tool the description never mentions paging behavior or what the query matches against, leaving gaps an agent must discover by trial.

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 burden; it identifies only the 'query' filter semantically ('by query') and gives no meaning for limit or offset. Coverage of 1 of 3 parameters is weak compensation for an entirely undocumented 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?

The description gives a specific verb ('Find') and resource ('company users'), plus the downstream purpose of obtaining user IDs for ownership and membership, which separates it from kaiten_get_current_user (single user). It does not name a sibling alternative explicitly, so it falls 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: 'to obtain user IDs for ownership and membership' hints at when an agent would call it (before kaiten_add_card_member or setting ownership). There is no explicit when-not guidance, no mention of an unfiltered listing mode, and no named alternative such as kaiten_get_current_user for the current user case.

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?

The annotations already establish that this is a non-read-only, destructive, non-idempotent operation in an open-world system. The description adds the need for an explicit valid destination, but gives no further detail on validation, failure behavior, or constraints on the move.

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-load the operation and then state the ID-discovery prerequisite. There is no redundant or unnecessary wording.

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?

Together with the required four-parameter schema, annotations, and output schema, the description provides enough context for basic selection and invocation. Naming kaiten_list_boards, kaiten_list_columns, and kaiten_list_lanes and noting any cross-board or lane constraints would make it more 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?

With 0% schema description coverage, the description usefully clarifies that board_id, column_id, and lane_id form the target and must be valid IDs obtained elsewhere. It does not explain how to obtain card_id or map each target ID to a specific navigation tool, so compensation for the undocumented schema is only 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?

The description uses a specific verb and resource—moving a card—and identifies the complete destination as a board, column, and lane. It does not explicitly distinguish this operation from siblings such as kaiten_update_card, so it stops short of the highest score.

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 second sentence gives a concrete prerequisite: obtain valid target IDs with the navigation tools before calling. It does not name the relevant list tools or explain when another card operation would be preferable, but the intended workflow is clear.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the mutation profile is covered structurally. The description usefully narrows that destructiveness by stating both cards survive the unlink, and it discloses the return value as the confirmed ID, which goes beyond the annotations.

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 operation and followed by the ID-format caveat and the return value. No redundant phrasing and nothing 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 tool with a full annotation set and an output schema, the description covers what is destroyed, which ID to pass, and what comes back. Only the parent_card_id's meaning is left implicit.

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 parameter meaning. It does clarify that child_card_id must be a card ID rather than a relationship ID, which is real disambiguation, but parent_card_id is never explained and no format or validation detail is added.

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: "Unlink child_card_id from parent_card_id." It immediately clarifies the operation is a relationship removal, not a card deletion, which cleanly separates it from kaiten_delete_card and kaiten_add_card_child.

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 by the operation semantics and the caveat about which ID to supply, but there is no explicit when-to-use versus when-to-use-an-alternative guidance (e.g., how this relates to kaiten_list_card_children or kaiten_add_card_child). An agent can infer intent, but nothing states prerequisites or the reverse operation.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds only the word 'native', which is never defined and does not clarify permanence, permissions needed, or whether the external target 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?

A single front-loaded sentence with no filler or redundancy. It is tight, but its brevity comes at the cost of the semantics noted elsewhere rather than from judicious editing.

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 destructive, non-idempotent mutation with two undocumented parameters, the description is too thin. The output schema relieves it of explaining return values, but nothing covers preconditions, irreversibility, or what 'native' excludes.

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%: neither card_id nor link_id is documented in the schema. The description implicitly maps 'card' and 'link' to those parameters but adds no format, sourcing, or constraint details, so an agent still cannot tell how to obtain a valid link_id.

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 (native external link) scoped to a card, which distinguishes it cleanly from kaiten_add_card_external_link, kaiten_update_card_external_link and kaiten_list_card_external_links. The qualifier 'native' is unexplained but the core action 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?

No when-to-use guidance and no mention of the obvious precondition: obtaining a valid link_id, most likely via kaiten_list_card_external_links. It also does not say how removal differs from updating a link with kaiten_update_card_external_link.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether the removed user loses access immediately, whether the operation is recoverable, or whether it requires admin rights on the card.

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 with the action front-loaded and no filler. It is efficiently sized, though its brevity is partly a symptom of under-specification rather than disciplined editing.

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?

This is a destructive mutation with two undocumented parameters and 0% schema coverage, yet the description is one clause long. An output schema exists so return values need not be explained, but the missing parameter sourcing, prerequisites, and irreversibility note leave real gaps for a delete-style 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%, so the description must carry the burden for both parameters. It mentions member_id only in passing ('using its member_id') and never explains card_id, where a member_id comes from (e.g., kaiten_list_card_members or kaiten_list_users), or ID constraints beyond the schema's positive-integer rule.

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 names a specific verb and resource ('Remove a membership from a card'), which is clearly distinct from the sibling 'kaiten_add_card_member'. It does not explicitly name alternatives, but the operation itself 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?

There is no guidance on when to use this instead of 'kaiten_add_card_member' or 'kaiten_update_card_member_role', no prerequisites, and no statement about what happens to the underlying user or card. Usage must be inferred entirely 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds essentially nothing beyond that: it does not say what happens if the tag is not attached, whether the tag itself is deleted or merely detached, or whether any permission scope applies. Naming tag_id as the selector is the only extra signal.

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 with the identifying detail (tag_id) front-loaded and no filler. It is efficient, though its brevity is as much under-specification as concision.

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 tool is simple and has an output schema, so return values need no explanation. However, with a destructive, non-idempotent mutation whose two required parameters are entirely undocumented in the schema, the description leaves too much for the agent to infer about parameters and side effects.

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 neither parameter carries a description or enum, so the description must compensate. It only mentions tag_id and never explains card_id, leaving one of two required integer parameters fully undocumented and adding no format or constraint details for the other.

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 combination ('Detach a tag from a card'), which is concretely distinguishable from the sibling 'kaiten_add_card_tag' and from 'kaiten_list_card_tags'. It stops short of an explicit sibling contrast, but the intent 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?

There is no guidance on when to use this versus alternatives such as kaiten_add_card_tag, kaiten_list_card_tags, or kaiten_update_card. No preconditions, no exclusions, and no mention of whether the card must already have the tag.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered structurally. The description adds only the state transition (archived -> live); it says nothing about required permissions, what happens when restoring an already-live card, or where the card reappears on its 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification for a state-changing operation.

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?

An output schema exists, so return values need not be described, and the tool has only one parameter, keeping the required scope small. Still, for a non-idempotent, destructive-flagged mutation the description omits error conditions (non-archived card, missing card) and any side-effect notes, leaving clear gaps.

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 parameter, card_id, with 0% schema description coverage, and the description says nothing about it — not even that it identifies the archived card. The schema's name and integer/exclusiveMinimum constraints carry all the meaning, so the description fails 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?

The description uses a specific verb ('Restore') and resource ('an archived card') and names the resulting state ('live condition'), which lets an agent distinguish it from kaiten_archive_card and kaiten_delete_card in the sibling list. It stops short of explicitly naming those siblings as inverses/alternatives.

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 precondition (the card must already be archived) is implied by 'an archived card', so usage is inferable. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of what to do if the card is already live, and no reference to sibling tools such as archive_card or delete_card.

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?

Beyond the supplied readOnly/idempotent/openWorld annotations, the description discloses that results are summaries plus a cursor, and that continuation requires reusing the same filters. However, it refers to 'next_cursor' while the schema parameter is named 'cursor', which muddies the pagination contract for an agent that has to act on it.

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, then workflow, then pagination and escalation to the detail tool, with no filler sentences. The identity warning is slightly tangential but earns its place as a guardrail against a common failure mode.

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?

An output schema exists and the description appropriately summarizes return shape instead of restating it, and the workflow guidance is complete. What is missing is meaningful coverage of a large, entirely undocumented 18-parameter filter surface, which is the main thing an agent must get right 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 description coverage is 0% across 18 parameters, so the description carries the full burden and falls well short: only responsible_ids and the cursor are touched on. It leaves opaque the distinctions and semantics of owner_ids vs member_ids vs responsible_ids, states, asap, overdue, archived, lane_id, column_id, board_id, space_id, tag_ids, and type_ids.

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 names a specific verb and resource ('Search Kaiten tasks (cards) with filters') and explicitly distinguishes itself from the detail-retrieval sibling by saying 'Fetch details with kaiten_get_card.' An agent can tell it apart from kaiten_get_card without opening either 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 an explicit workflow: for 'my tasks', read kaiten_get_current_user and its connection guidance first, then default to responsible_ids for that user, with a clear negative instruction not to infer identity from OS or OpenAI names. It also routes to the correct alternative (kaiten_get_card) when full details are needed.

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?

Annotations already declare this is a non-idempotent, destructive mutation; the description adds genuinely new behavioral detail absent from them – that updates are partial/merge-style, that null is the deletion mechanism, and that definitions/options cannot be modified through this tool. It stops short of stating failure modes for wrong value formats or whether a bad property key aborts the whole call.

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 key convention and partial-update rule before the format catalogue. Every clause supplies non-redundant information; there is no restating of the tool name or filler.

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

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

For a mutation tool with nested/anyOf values, a 0%-coverage schema and an output schema already present, the description covers the essentials an agent needs to construct a valid call. The remaining gap is procedural: it never says the agent must first resolve property IDs and option IDs via the read-only property/catalog/directory endpoints.

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 0% schema description coverage, the description carries the full burden and does so: it explains the id_<propertyId> key naming, the omit-vs-null semantic, and the exact value shapes per property kind (scalar, select ID array, catalog string ID, directory UUID array, date object with date/time/tzOffset). The open-ended value schema would otherwise give an agent nothing to work with.

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?

Names a specific verb and resource ('Set existing card properties') and scopes it precisely with the 'id_<propertyId>' key convention. It is clearly distinguishable from siblings such as kaiten_update_card and the read-only kaiten_list_custom_properties / kaiten_get_custom_property tools, which the closing clause implicitly separates out.

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 partial-update rule ('Omitted properties remain unchanged; null clears a value') tells the agent how to call it, and 'Definitions and options are read-only' signals that schema discovery belongs elsewhere. However, no sibling is named as the way to discover property IDs and value formats before calling, so the routing advice is implied rather than explicit.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the description isn't responsible for the safety profile. It does add genuinely useful behavior beyond that: PATCH semantics (omitted fields remain unchanged), the null-clears-fields convention, and the Markdown format for the description field. What's missing is any hint about permissions, side effects on notifications or history, or how destructive updates are surfaced to users.

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, each earning its place: the action first, then the patch semantics, then the format note. No filler or repetition.

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

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

An output schema exists, so return values needn't be described. But for a destructive, non-idempotent mutation tool with a nested eight-field changes object and zero schema descriptions, the definition is thin — an agent still has to open the schema to know what it can actually change.

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 nested `changes` object has eight undocumented fields, so the description has to carry the burden. It partially does by explaining the omission/null semantics and the Markdown format, but it never names the updatable fields (title, type_id, owner_id, due_date, asap, size_text, description, due_date_time_present) or which ones accept null clearing.

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+resource combination ("Update the supplied card fields") that an agent can map directly to a mutation on a card. It does not, however, distinguish itself from siblings like kaiten_move_card, kaiten_archive_card, or kaiten_set_card_properties, which could all plausibly be seen as ways to modify a 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?

There is no guidance on when to use this tool versus alternatives such as kaiten_set_card_properties, kaiten_move_card, or kaiten_archive_card. Usage is only implied by the word "update" — no exclusions, no prerequisites, no conditions.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true and readOnlyHint=false, so the safety profile is carried by structured data. The description adds nothing beyond that - it does not say whether 'changes' is a partial patch or a full replace, what happens to an existing description when only url is supplied, or what the destructive hint means in practice.

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 single sentence is front-loaded and free of filler, but at nine words it is under-specified rather than concise; there is room for a clarifying clause about the changes payload without bloat.

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?

Although an output schema exists (so return values need not be described), the tool is a destructive, non-idempotent mutation with a nested payload and zero schema descriptions. A single sentence is not enough for an agent to call it safely without guessing at update semantics.

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 tool has three required parameters, including a nested 'changes' object with 'url' and 'description' (the latter nullable). The description does not explain that changes is a partial-update payload, nor that a null description clears the field, so it fails to compensate for the complete absence of schema descriptions.

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 ('Update') and resource ('a native external link on a card'), which distinguishes it from the sibling add/remove/list external-link tools. However, the word 'native' is unexplained and there is no explicit differentiation statement naming its siblings.

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 guidance on when to use this tool versus kaiten_add_card_external_link or kaiten_remove_card_external_link, nor any prerequisites such as needing the link_id from kaiten_list_card_external_links. The agent must infer the usage context 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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered; the description adds only the return fields, which the output schema already provides. It does not disclose what happens to the member's previous role (the thing being 'destroyed'), whether the operation requires card-admin rights, or what error occurs if member_id is not on the card.

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 the action stated first and the id-source hint immediately after; nothing is padded. 'with type 2' is partly redundant with the schema const but serves as a quick signal of the tool's narrow purpose.

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 tool is simple (3 params, one a fixed const) and an output schema exists, so return-value explanation is not needed. However, for a tool flagged destructive with a non-idempotent hint, the description should mention that the existing role is overwritten and whether repeated calls are effectively idempotent, which would prevent an agent from mis-sequencing calls.

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 burden, and it partially does by tying member_id to the id returned by list_card_members. It adds nothing for card_id and merely restates that type is 2, which the schema already pins with a const. Roughly half the parameters get 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?

States a concrete verb and outcome ('Make a card member responsible') plus the fixed role type, which distinguishes it from add_card_member/remove_card_member among the siblings. It never explains why the tool is named 'update_role' while only ever setting type 2, but an agent can still tell what it 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?

The only guidance is procedural: 'Use the membership id returned by list_card_members', which points to the right upstream tool for obtaining member_id. There is no statement of when to use this versus kaiten_add_card_member or kaiten_remove_card_member, and no prerequisites or preconditions are given, so usage is implied rather than specified.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds nothing about what destruction means here (e.g. that reordering shifts other checklists) or whether changes are reversible. For a mutation tool with a destructive flag, the single sentence leaves the behavioral picture entirely to the annotations.

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 clean, front-loaded sentence with no filler, but its brevity is under-specification rather than efficiency. The structure is fine; the content volume is too low for a three-parameter destructive mutation.

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 destructive, non-idempotent, open-world mutation with a nested parameter object and an output schema, the description omits preconditions, side effects on sibling items when order changes, and any scope notes. An output schema justifies skipping return-value explanation, but the behavioral gaps remain.

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 only hints at the nested `changes` fields ("name or order") and says nothing about `card_id`, `checklist_id`, or that `changes` rejects additional properties. Partial but not adequate compensation for three undocumented required parameters.

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 ("Change a checklist") plus the two mutable fields (name, order), so an agent knows it mutates the checklist container rather than its items. It does not explicitly differentiate itself from kaiten_update_checklist_item or kaiten_create_checklist, leaving that to the tool 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?

There is no guidance on when to use this versus kaiten_update_checklist_item, kaiten_delete_checklist, or kaiten_create_checklist, and no prerequisites such as needing the card_id/checklist_id first. Usage is only inferable from the phrase "name or order".

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?

The annotations already declare destructiveHint=true and idempotentHint=false, and the description adds a genuinely useful behavioral rule: null clears text, due_date or responsible_id. However, it never states whether omitted fields are preserved (partial vs. full replace), which is central to a destructive update tool, and gives no warning about irreversibility.

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 compact sentences with the primary action first and the null-clearing rule immediately after; there is no filler wording.

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 destructive nested-object update with zero schema descriptions, the definition covers the null semantics but leaves out partial-update behavior, sort_order, and any mention of the destructive/idempotency implications. An output schema exists, so return values need not be described.

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 explains the semantics of the null values for text, due_date and responsible_id and the meaning of checked, which helps. It omits sort_order entirely and says nothing about the identifier parameters (card_id, checklist_id, item_id) or the nested 'changes' wrapper itself.

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 plus resource ('Change checklist item fields'), which clearly separates it from sibling add_checklist_item and delete_checklist_item. It doesn't explicitly name those siblings, but the mutation scope 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?

There is no when-to-use guidance, no mention of when to prefer add/delete checklist item tools, and no prerequisites or permission notes. Usage is only implied by the word 'Change'.

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