kaiten-mcp

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

No annotations are supplied, so the description carries the full behavioral burden. It explains the rendering effect of the link, which is useful, but says nothing about required permissions, duplicate-link behavior, error cases, or what is returned after the mutation.

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

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

Two short sentences with zero waste: the action comes first and the usage rationale second. Nothing is redundant with the tool name or schema.

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

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

For a simple three-parameter mutation with no output schema, purpose and preferred usage are covered. However, with no annotations the description should say more about mutation semantics (idempotency, duplicates, permissions) to be fully 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 100% and all three parameters (url, card_id, description) are documented in the schema. The description adds only the merge-request example for url and does not clarify the optional caption parameter, so baseline 3 applies.

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

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

States a specific verb and resource ("Привязывает к карточке внешнюю ссылку") with a concrete example (merge request). It differentiates itself from the comment path, though it does not explicitly distinguish itself from the update/remove/list external-link 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?

Gives a clear usage context and an explicit alternative: prefer this over a comment because the link renders as a linked resource and doesn't clutter the feed. No when-not guidance (e.g., duplicate link handling) is provided, keeping it below a 5.

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

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

No annotations are supplied, so the description must carry the entire behavioral burden, and it does not. It does not say whether adding an existing member is a no-op or an error, whether the added user receives a notification, or what the tool returns on success. For a mutation tool with zero annotation coverage this is a substantial gap.

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 filler and the action front-loaded. It is sized appropriately for what it says, though the brevity reflects thin content rather than disciplined editing of rich content.

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

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

A two-required-parameter mutation tool with no annotations and no output schema needs more than one sentence: idempotency, permission requirements, and error behavior are all unstated. The schema covers the parameters, but nothing covers the call's 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?

Schema description coverage is 100% — both card_id and user_id carry Russian descriptions — so the schema already documents the two parameters. The description adds nothing beyond restating that a user is added to a card, which is the baseline-3 case where the schema does the work.

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: adding a user as a member of a card. That is unambiguous and the sibling list contains kaiten_remove_card_member, so the direction of the operation reads clearly from the name plus this sentence. It stops short of explicitly contrasting with the remove counterpart, which keeps it at 4 rather than 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 to add a member versus using kaiten_remove_card_member to undo it, no prerequisites about the caller's permissions on the card, board, or space, and no note on whether the target user must already be visible to the caller. The single sentence implies usage but excludes nothing.

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

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

With no annotations, the description carries the full burden, and it does disclose the important side effect that the tag is created if it does not exist. It says nothing about what happens if the tag is already on the card (duplicate vs. no-op), what the response contains, or any permission requirements.

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, the resource, and the creation side effect front-loaded; nothing is redundant or padded.

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-required-parameter tool with no output schema and full schema coverage, the description covers the essential behavior including auto-creation. The only missing piece is what happens on an already-present tag, which would matter for repeated 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the tag is resolved by name rather than ID and is auto-created, which tells the agent how 'name' is interpreted even though the schema only says 'Имя тега'.

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 ('Добавляет тег к карточке') and adds the key resolution rule ('по имени'). It is clearly distinguishable from the sibling kaiten_remove_card_tag, though it does not name it or any other alternative 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?

Usage is implied by the operation itself — you call it when a card needs a tag — but the description never says when to prefer this over removing/re-listing tags, nor does it mention that kaiten_list_tags exists for discovering existing tag names before adding.

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

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

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It says nothing about required permissions, where the checklist is placed among existing checklists, or what the call returns; 'Создаёт' only implies a write, leaving the agent to infer the rest.

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 repetition. It is efficient, though its brevity leaves the surrounding gaps noted in other dimensions.

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 create/mutation tool with no annotations and no output schema, the description is too thin: it does not say what happens on success, whether the checklist ID is returned (needed to then call kaiten_add_checklist_item), or how duplicates are handled.

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

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

Schema description coverage is 100% — both card_id and name are documented in the schema — so the baseline of 3 applies. The description adds no extra meaning such as ID format, name constraints, or uniqueness 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 states a specific verb and resource ('Создаёт новый чек-лист') and scopes it to a card ('на карточке'), so an agent can tell it creates a checklist container rather than an item or a listing. It does not explicitly contrast with siblings like kaiten_add_checklist_item or kaiten_list_checklists, which keeps it just short of a 5.

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

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

There is no guidance on when to use this versus kaiten_add_checklist_item (which adds entries to an existing checklist) or kaiten_list_checklists. No prerequisites, no mention of needing an existing card, and no exclusions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing beyond the mutation itself: not whether the item is appended at the end, what permission level is needed, whether the operation is idempotent, or what is returned. For an unannotated write tool this is a significant gap.

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 filler, front-loading the action and target. It is efficient, though its brevity is partly the source of the missing behavioral 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?

For a mutation tool with no annotations and no output schema, the description should say more about effects and results. It omits preconditions (valid card/checklist IDs) and whether the created item or its position is returned.

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

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

Schema description coverage is 100% and each of the three parameters (text, card_id, checklist_id) is documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Добавляет пункт в чек-лист карточки'), which lets an agent distinguish it from kaiten_delete_checklist_item, kaiten_update_checklist_item and kaiten_add_checklist. It does not name those siblings explicitly, 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 to use this versus updating or deleting a checklist item, and no stated prerequisites such as the checklist needing to already exist on the card. The only implied context is that a card and checklist ID are required.

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

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

No annotations are provided, so the description carries the full burden. It does not say whether the caller needs permissions, whether duplicate entries are allowed, how role_id affects the entry, or what the operation returns, beyond the fact that it is an additive write.

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, with the core action stated first. It is efficient, though it is minimal to the point of under-specification given the tool's write behavior.

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 five-parameter mutation tool with no annotations and no output schema, the description covers neither the result of the call nor how fields such as role_id, for_date, and comment affect the entry. It is too thin for a write operation with no supporting structured metadata.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, including minimal units. The description only repeats that time_spent is in minutes, which adds no meaning beyond what the schema provides.

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 clear verb and resource: it adds a time-tracking entry to a card. An agent can tell this apart from kaiten_list_time_logs and kaiten_delete_time_log by the verb alone, 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 guidance on when to use this tool versus the related kaiten_list_time_logs or kaiten_delete_time_log, and no prerequisites or exclusions are stated. The usage is only implied by the verb 'Добавляет'.

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

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

With no annotations, the description must carry the behavioral burden; it does disclose the resulting state (condition = 2) and that the card is not removed, which is genuine non-destructive context. It says nothing about permissions, whether archiving is reversible/unarchivable, or what happens if the card is already archived.

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 zero waste; the core action is front-loaded and the clarifying clause follows immediately. Nothing to trim.

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 single-parameter mutation with no output schema and no annotations, the description covers the essential effect. It falls short on reversibility and error/already-archived behavior, which an agent would want before calling a state-changing 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?

Only one parameter (card_id) with 100% schema description coverage, so the schema already documents it fully. The description adds no format or constraint detail beyond the schema, which is the expected baseline for a single well-documented parameter.

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

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

States a specific verb and resource ('Архивирует карточку') and adds the resulting state (condition = 2). The clause 'не удаляя её' implicitly separates it from kaiten_delete_card, 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?

The phrase 'не удаляя её' hints that this is the non-destructive alternative to deletion, but there is no explicit statement of when to choose archive over delete/update or any prerequisite context. Usage is implied 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?

With no annotations, the description carries the full burden. It confirms this is a creation operation but discloses nothing about side effects, permissions, whether the card is immediately visible in the column, or what the response contains (e.g. the new card's ID, which callers need to chain further actions).

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

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

Two short sentences with the core action front-loaded and no filler. The second sentence largely echoes the schema's required array, which is mild redundancy but otherwise efficient.

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 10-parameter mutation tool with no annotations and no output schema, the description is too thin: it omits return-value expectations, error/permission behavior, and how the many optional fields affect the created card. An agent can call it but is poorly prepared for the result.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema. The description only restates the three required fields, adding no meaning beyond the schema (e.g. how lane_id interacts with column_id, or asap semantics), so baseline 3 applies.

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

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

States a specific verb and resource ('Создаёт новую карточку'), which implicitly contrasts with siblings like kaiten_update_card or kaiten_delete_card. It does not explicitly name a sibling or scope the operation (e.g. where the card lands), 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?

The description only enumerates required fields; it never says when to use this tool versus alternatives such as kaiten_update_card or kaiten_move_card, nor any prerequisites (e.g. needing valid board/column IDs from listing tools). No exclusions or context are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the text supports markdown, but says nothing about side effects (notifications to card members), permission requirements, whether the comment is returned, or error behavior for 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 sentences with no filler, and the core action is front-loaded. It is arguably under-specified rather than over-long, 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?

For a simple two-parameter creation tool with a fully described schema, the definition is minimally sufficient. However, with no annotations and no output schema, it leaves the agent without any sense of what is returned or what side effects to expect.

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

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

Schema description coverage is 100%, so both parameters (card_id, text) are already documented in the schema. The description adds only one semantic detail beyond that — markdown support in the text field — which is the correct baseline 3 when the schema does the heavy lifting.

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 ('Добавляет комментарий к карточке'), which clearly separates it from siblings like kaiten_list_comments, kaiten_update_comment and kaiten_delete_comment. It does not explicitly name those alternatives, but the create-vs-list/update/delete distinction is inferable.

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 the sibling comment tools, no prerequisites (e.g. card must exist, permission needed), and no exclusions. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the most important trait: the deletion is irreversible. It says nothing about required permissions, whether attached comments/checklists/time logs are cascaded or orphaned, or whether any confirmation step exists — significant gaps for a destructive mutation.

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

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

Two short sentences, both front-loaded: the action first, the irreversibility warning second. Nothing is wasted.

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

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

For a one-parameter tool with no output schema (nothing to return) and no annotations, the description covers the essentials but omits the cascade/permission consequences an agent needs before committing to an irreversible write.

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 a single parameter and schema description coverage is 100%, so the schema already defines 'card_id' fully. The description's 'по ID' merely restates it with no added format, source, or retrieval hints, making baseline 3 correct.

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?

A specific verb plus resource ('Удаляет карточку') with the lookup key ('по ID') stated, so the agent knows exactly what it does. It does not, however, distinguish itself from the far more common sibling alternative kaiten_archive_card, which is the nearest ambiguity in this toolset.

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?

'используйте осознанно' is a caution, not usage guidance — it does not tell the agent when to prefer this over kaiten_archive_card, kaiten_update_card, or member/tag removal. Usage is only implied by the tool's purpose.

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

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

No annotations are provided, so the description carries the full burden, yet it only restates 'delete'. It does not disclose that the operation is irreversible, whether permissions or card access are required, whether item ordering is renumbered, or what happens when an ID is invalid — all critical for a destructive tool.

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

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

A single front-loaded sentence with zero padding. It is efficient, though its brevity reflects under-specification rather than disciplined economy.

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

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

For a destructive, three-ID mutation tool with no annotations and no output schema, the description leaves out nearly everything an agent needs: irreversibility, failure modes for stale IDs, and any confirmation of effect. The schema covers parameters, but behavior is essentially 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 100%, with all three IDs (card_id, checklist_id, item_id) documented in the schema. The description adds nothing about the required hierarchy or ID semantics, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Удаляет пункт чек-листа карточки' — deletes a card's checklist item), which is unambiguous. It does not differentiate itself from sibling mutation tools such as kaiten_update_checklist_item or kaiten_delete_card, 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 to use this versus kaiten_update_checklist_item (to clear content) or kaiten_add_checklist_item, and no mention of prerequisites such as the parent checklist needing to exist. The only implied usage comes from the verb itself.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about irreversibility, required permissions, or what happens on success/failure. For a destructive delete operation this is a significant omission.

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

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

A single short sentence, front-loaded and free of waste. It is arguably under-specified rather than bloated, but it is structurally clean.

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

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

With no annotations, no output schema, and a destructive operation, the description should warn about irreversibility or permissions but does not. The agent knows the action but not its consequences or failure modes.

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

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

Schema description coverage is 100%, with both card_id and comment_id documented in the schema itself, so the description cannot add much. The baseline of 3 applies since the schema does the heavy lifting.

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 ('Удаляет комментарий карточки' – deletes a card comment), which is unambiguous about what is removed. It does not name or differentiate from sibling tools like kaiten_update_comment or kaiten_delete_checklist_item, keeping it just short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as kaiten_update_comment, nor any prerequisites or exclusions. The agent must infer everything about context 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?

No annotations are provided, so the description carries the full disclosure burden for a destructive operation. It says the record is deleted but omits whether the deletion is permanent, what permissions are required, and whether any related card totals are recalculated. For an irreversible mutation with zero annotation coverage, this is a substantial gap.

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, and the destructive verb is front-loaded. It is under-specified rather than verbose, which the other dimensions already capture.

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, two-parameter mutation with no annotations and no output schema, the description should at minimum flag irreversibility and any required permissions. Instead it offers one bare sentence, leaving the agent without the behavioral context needed to invoke it responsibly.

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

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

Schema description coverage is 100%, with both card_id and time_log_id documented in the schema, so the baseline of 3 applies. The description adds no additional semantics such as how to source these IDs or whether time_log_id is scoped to card_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 states a specific verb and resource ('Удаляет запись учёта времени с карточки'), which clearly identifies a deletion of a time-log entry tied to a card. It is distinguishable from kaiten_add_time_log and kaiten_list_time_logs by the verb alone, though it never explicitly names those 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_time_log, kaiten_list_time_logs, or how to obtain the required time_log_id. No prerequisites, no exclusions, no mention of consequences — the agent must infer everything from the name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that columns and lanes are usually nested in the response, which is valuable behavioral context, but it does not clarify whether that nesting is guaranteed, what happens for an invalid ID, or permission requirements.

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

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

Two short sentences, front-loaded with the core action and then the useful response detail. No wasted 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 simple one-parameter read tool with no output schema, the description covers the essential behavior and notes the typical nested payload. Minor gaps around error behavior and guarantees keep it from a 5.

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

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

Schema description coverage is 100% and the single board_id parameter is documented in the schema as 'ID доски'. The description restates 'по ID' without adding format or constraint details, so baseline 3 applies.

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

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

States a specific verb and resource ('Возвращает доску по ID' – returns a board by ID) and adds that columns and lanes are usually embedded. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like kaiten_list_boards or kaiten_get_space.

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 required board_id and the 'get by ID' semantics, but there is no explicit guidance on when to use this versus kaiten_list_boards or the column/lane list tools. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full disclosure burden. It does list example fields returned (описание, участники, теги, сроки), which is genuinely useful, but says nothing about permissions, whether archived cards are returned, error behavior for bad IDs, or payload size.

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 the core action first and the field enumeration as a compact parenthetical. Nothing extraneous.

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

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

For a one-parameter read with no output schema, the description usefully previews the returned payload. Sufficient to call correctly; only missing caveats around access and archived-state behavior.

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

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

Only one parameter, fully documented in the schema at 100% coverage with 'ID карточки'. The description's 'по ID' merely restates the schema, adding no format or sourcing detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Возвращает карточку по ID') and clarifies the retrieval scope ('со всеми полями'). The 'by ID' framing implicitly separates it from kaiten_search_cards and the list_* siblings, 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?

Usage is implied rather than stated: the agent can infer this is the direct-lookup tool when a card ID is already known. There is no explicit 'use this instead of search_cards when...' guidance or preconditions about archived/deleted cards.

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

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

No annotations exist, so the description carries the full load. 'Возвращает данные' implies a read-only lookup, but it says nothing about what fields come back, whether an invalid/expired token causes an error, or whether any authorization scope is required — meaningful gaps for a no-annotation tool.

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

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

Two short sentences with the identity of the resource front-loaded and the practical purpose second. No filler.

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

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

For a trivial no-param read with no output schema, the description covers what the tool is and why to call it. It could add a hint about the returned fields (id, name, email) to be fully self-sufficient, but nothing needed to invoke it is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly frames the call as independent of any inputs, since the user is identified by the token 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?

States a specific verb+resource ('Возвращает данные текущего пользователя') and disambiguates which user by tying it to the API token in use. It implicitly separates itself from kaiten_list_users by focusing on the token owner, though it never names that sibling 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?

Gives a concrete use case: find your own user id for planning tools (kaiten_plan_day etc.). That is real routing guidance, but there is no explicit 'when not to use' or a named alternative such as kaiten_list_users for other users.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the operation itself — no error behavior for a nonexistent ID, no permission/auth requirements, no indication of what a space object contains. It is effectively a restatement of the tool name.

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

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

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

There is no output schema and no annotations, so the description should at least sketch what a returned space looks like or how failures surface. For a lookup tool an agent will call to resolve an ID before chaining into kaiten_list_boards or kaiten_get_board, that missing return-shape context leaves a real 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 100% ('ID пространства'), so the single parameter is fully documented structurally. The description adds nothing beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Возвращает одно пространство по его ID' — returns a single space by its ID). The word 'одно' (one) implicitly contrasts with kaiten_list_spaces, but the sibling is never named.

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: 'by its ID' suggests this is for fetching a known space rather than enumerating them. There is no explicit when-to-use/when-not, no mention of kaiten_list_spaces as the alternative, and no prerequisite 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?

No annotations, so the description carries the full burden. It usefully discloses the KAITEN_DEFAULT_SPACE_ID fallback behavior, which isn't purely derivable. But it doesn't state read-only nature explicitly, pagination, or return shape — gaps for a no-annotation tool, though 'returns' weakly signals a read.

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

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

Two short sentences, front-loaded with the core action, and the fallback detail follows. Efficient with no waste, though slightly redundant with the schema's parameter description.

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 one-parameter read tool with no output schema, the description covers the key invocation detail (default space). It doesn't describe the return list shape, which the absence of an output schema leaves unaddressed, so it's adequate but not 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?

Schema coverage is 100% and the single space_id parameter is already documented in the schema, including the default-from-config note. The description largely repeats what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource: returns boards (boards) inside a space. An agent can distinguish it from kaiten_get_board and kaiten_list_spaces. It doesn't explicitly contrast with siblings, 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?

The default-fallback sentence implies when the parameter can be omitted, but there's no explicit when-to-use/when-not guidance or naming of alternatives. Usage is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says it returns links. It omits pagination, ordering, permission requirements, and what happens when a card has no links or does not exist.

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 zero filler, front-loading the action and resource. It is efficient, though the brevity comes 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?

For a one-parameter read tool with no output schema and no annotations, this is minimally adequate. The agent can invoke it, but it learns nothing about the return shape or edge cases.

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

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

Schema coverage is 100% and the single card_id parameter is documented in the schema ('ID карточки'), so the description adds nothing beyond it. The baseline of 3 applies when the schema does the work.

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 ('Возвращает внешние ссылки ... карточки'), so an agent knows it reads a card's external links. The 'list' semantics are implied by 'Возвращает' but the description never explicitly contrasts with the add/update/remove external-link 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 statement of when to use this tool versus kaiten_add_card_external_link, kaiten_update_card_external_link, or kaiten_remove_card_external_link, and no preconditions or exclusions. Usage must be inferred entirely from the 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?

No annotations are provided, so the description carries the burden. 'Возвращает' implies a harmless read and the company-scoping is disclosed, but nothing is said about auth requirements, result size, or whether the list is filtered/paginated.

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. It is appropriately sized for a no-argument list tool, though it leaves no room for any supplementary 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?

With no output schema and no annotations, the agent is not told what a card type record contains (id, name) or how to use the result downstream. For a trivial reference-list endpoint this is adequate but leaves the consumption path 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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly signals the tool is argument-free.

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 ('Возвращает доступные типы карточек') and scopes it to 'компании'. The resource is unambiguous and distinct from sibling list tools (tags, spaces, boards, columns, lanes), though the description does not explicitly contrast with them.

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

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

The description says what the tool returns but nothing about when to reach for it — e.g., to resolve a type_id before kaiten_create_card or kaiten_update_card. No prerequisites, no exclusions, no alternatives are mentioned.

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

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

With no annotations, the description carries the full burden; it does disclose that items are returned nested with the checklists, which is useful behavioral context. However it says nothing about permissions, behavior when a card has no checklists, or whether results are paginated.

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 zero filler and the key fact (items included) front-loaded. It is arguably too terse rather than too long, but nothing in it is wasted.

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

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

For a simple single-parameter list tool with no output schema, the description covers what is returned at a high level. It leaves the agent without knowledge of error cases, empty-result behavior, or ordering, which are the remaining 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?

Schema coverage is 100% with a single required card_id already documented, so the schema does the work. The description adds no format, sourcing, or validation detail beyond what the schema provides, matching the baseline 3 for a single fully-described parameter.

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

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

States a specific verb and resource ('Возвращает чек-листы карточки') and clarifies the payload includes checklist items, which distinguishes it from item-level tools. It does not explicitly contrast with siblings like kaiten_add_checklist or kaiten_list_card_external_links, 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 statement of when to use this tool versus kaiten_add_checklist, kaiten_add_checklist_item, or kaiten_update_checklist_item, and no prerequisites or exclusions. The read-only intent is only implied by the verb 'Возвращает'.

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

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

No annotations are provided, so the description must carry the burden, and it does disclose the key semantic detail that column.type maps to 1/2/3 (queue/in-progress/done) — genuinely useful beyond the schema. However, it says nothing about read-only safety, ordering, permissions, or pagination 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?

Two short sentences, front-loaded with purpose and followed by the useful type-field semantics. No filler, though it is arguably slightly under-specified rather than maximally efficient.

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 single-param list tool, the description covers what is returned and one important return-value field. Missing are the required-ness of board_id (schema handles it) and any hint about what to do with columns downstream, but nothing critical is broken.

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

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

Only one parameter (board_id) and schema description coverage is 100%, so the schema fully documents it. The description adds no parameter-level detail, which is acceptable at this baseline.

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 ("Возвращает колонки доски"), so the agent knows it lists columns of a board. It doesn't explicitly distinguish itself from adjacent siblings like kaiten_list_lanes or kaiten_get_board, but the resource 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 guidance on when to call this versus kaiten_get_board (which may already include columns) or kaiten_list_lanes. The agent must infer the use case 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at a read operation but says nothing about pagination, ordering, result limits, permissions, or whether deleted comments are included — all material for a list-style endpoint.

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 no filler, so nothing is wasted — but it is under-specified rather than concise, and it omits the front-loaded details (read-only nature, pagination) an agent would want before calling.

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 param, no nested objects, no output schema), so the description need not explain return values. Still, for a listing endpoint with zero annotation coverage, the absence of any note on pagination or result shape leaves a real 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 100% and the single parameter (card_id, "ID карточки") is fully documented in the schema. The description adds no further meaning such as where to obtain the card ID or whether it accepts numeric IDs only, so the baseline of 3 applies.

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

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

The description states a verb and resource ("Возвращает комментарии карточки"), which is enough to understand it lists a card's comments. However, it essentially restates the tool name (kaiten_list_comments) plus the title ("Комментарии карточки") without adding scope or differentiation from siblings like list_checklists or list_time_logs.

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, no mention of prerequisites (e.g., needing card_id before listing), and no exclusions. The agent must infer usage entirely from the 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?

No annotations are provided, so the description carries the full behavioral burden. 'Возвращает' implies a read-only operation, but nothing is said about permissions, pagination, ordering, or what a lane object contains; for a zero-annotation tool this is a substantial gap.

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, front-loaded with the verb and the key disambiguating gloss. There is no padding, though the brevity borders on under-specification rather than tight writing.

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 one-parameter list tool with no output schema, the description covers the essentials of what is returned. It still leaves the agent guessing about lane contents, ordering, and how lanes relate to columns, which matters for a board-layout 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?

The single parameter board_id is fully documented in the schema (100% coverage) as 'ID доски', so the baseline applies. The description adds nothing about the parameter beyond restating the resource it identifies.

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 ('Возвращает дорожки ... доски') and disambiguates the term by glossing lanes as horizontal rows, which separates it from the column-listing sibling. It does not name kaiten_list_columns explicitly, so differentiation requires the agent to reason about the gloss.

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 statement of when to use this tool versus kaiten_list_columns, kaiten_get_board, or kaiten_list_boards. The only implied usage is 'you have a board_id and want its lanes', 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?

With no annotations provided, the description carries the full behavioral burden. It implies a read-only listing operation, but does not state whether the result is paginated, whether authentication or specific permissions are required, or how the output is shaped.

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

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

The description is a single efficient sentence with no filler. It front-loads the action and resource, making it immediately readable.

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 zero-parameter list tool with no output schema, the description covers the core operation but omits useful context such as pagination, ordering, and how this differs from kaiten_get_space. It is minimally adequate rather than fully complete.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool applies, and the description does not introduce confusing or contradictory parameter information.

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

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

The description gives a clear verb and resource: it returns all available Kaiten spaces. It is more specific than the title alone because it states the scope is all available spaces, though it does not explicitly distinguish itself from the sibling tool kaiten_get_space.

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 use this tool versus kaiten_get_space, kaiten_list_boards, or other sibling listing tools. The listing intent is implied by 'Возвращает все доступные пространства', but the description offers no alternatives 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?

No annotations are provided, so the description carries the full burden. 'Возвращает список' correctly signals a read-only listing, but it says nothing about result ordering, whether all tags are returned or paginated, or whether an empty list is possible.

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 filler, and the key information (it returns company tags) is front-loaded. It is efficient rather than padded, though it borders on under-specified.

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 zero-param list tool with no output schema, the description never indicates what a tag record contains (id, name, color) or whether the response is paginated, which an agent needs to plan the follow-up call to kaiten_add_card_tag.

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, which is the baseline-4 case; the empty schema is fully self-explanatory and the description introduces no parameter-related ambiguity.

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 ('Возвращает список тегов компании'), and the qualifier 'компании' distinguishes company-level tags from the card-level tag siblings (kaiten_add_card_tag / kaiten_remove_card_tag). It does not explicitly name those siblings, so 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?

No guidance on when to call this versus the card-tag tools or any other lookup. There is no mention of prerequisites, pagination, or what an agent should do with the returned 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?

With no annotations, the description carries the full behavioral burden and does not meet it. 'Возвращает' implies a read, but nothing is said about permissions, pagination, ordering, or what a time-log record contains for this listing operation.

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 front-loaded sentence with zero filler. Nothing is redundant with the name and nothing is wasted.

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

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

For a one-parameter read tool with full schema coverage, the definition is minimally sufficient to invoke it. However, with no annotations and no output schema, the agent learns nothing about result shape, pagination, or ordering, which leaves gaps for a listing 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?

There is a single parameter and schema coverage is 100% ('ID карточки' is documented in the schema), so the schema already does the work; baseline 3 applies. 'По карточке' in the description corroborates the parameter's role but adds no syntax or format detail beyond the schema.

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

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

States a specific verb (Возвращает) and resource (записи учёта времени) scoped to a card. An agent can distinguish this read operation from the sibling kaiten_add_time_log and kaiten_delete_time_log without opening the schema, though those siblings are not 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?

Usage is only implied: the phrase 'по карточке' tells the agent this is the card-scoped time-log reader, so calling it versus add/delete is inferable. There is no explicit when-to-use statement, no exclusions, and no mention of alternatives.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It states the tool returns a list and implies read-only operation, but does not disclose permissions, rate limits, pagination behavior, or return format details—significant gaps for a tool with no annotation coverage.

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

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

Two short sentences with zero waste; the core purpose is front-loaded and the filtering hint follows naturally. Highly efficient.

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 list tool with 3 parameters and no output schema, the description is adequate but incomplete. It covers purpose and filtering but omits return value details and pagination behavior, which are not otherwise provided since there is no output schema.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a small clarification for query (substring search), but limit and offset are not elaborated beyond the schema. The baseline of 3 is appropriate.

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

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

States a specific verb (returns) and resource (list of company users), clearly distinct from the sibling get_current_user. However, it does not explicitly name or differentiate from siblings, 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?

The description implies usage by mentioning filtering via query, but gives no explicit guidance on when to use this tool versus alternatives (e.g., get_current_user or other list tools). Usage is implied but not clearly contextualized.

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

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

No annotations exist, so the description bears the full behavioral burden for a mutating operation. It does not say whether the card must already exist, whether permission on both source and target board is needed, whether the move triggers notifications or reorders siblings, or what a failed/partial move does.

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, zero filler, with the action and destinations front-loaded. Nothing in the text is redundant with the title beyond what is needed.

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

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

A mutation tool with no annotations and no output schema needs to explain the return value and, critically, that only card_id is required even though a move requires at least one target. The description leaves both points unaddressed.

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

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

Schema description coverage is 100%, so the four params are already documented. The description restates the same three targets (column/lane/board) without adding semantics – notably it never explains how they combine or which are valid together, which is the one gap the schema leaves.

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

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

States a specific verb and resource plus the three possible destinations: "Перемещает карточку в другую колонку/дорожку/на другую доску". The note that it is a convenience wrapper over update implicitly separates it from kaiten_update_card, though the differentiation is not spelled 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?

Use is implied by "обёртка над update" – an agent can infer this is the narrow move operation versus the general update – but there is no explicit when-to-use guidance, no prerequisites, and no named alternative or exclusion.

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

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

With no annotations, the description carries the full burden. It does disclose two genuinely useful behavioral facts: only active cards are returned, and the date comparison is strict (today's due cards are excluded). However it says nothing about result ordering, pagination behavior, or permissions, which matters since there is no 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?

A single front-loaded sentence with zero filler, leading with the verb and resource before the filter condition. It is efficient, though so terse that it leaves no room for routing or behavioral 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?

For a 6-parameter read tool with fully documented schema and no output schema, the description covers the core semantics adequately. The remaining gaps are the relationship to sibling tools like kaiten_today_tasks and any note on result ordering or truncation at the limit.

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

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

Schema description coverage is 100%, so every parameter (role enum, limit, user_id default, board/space scoping, as_of_date format) is already documented in the schema. The description adds no parameter-level detail beyond confirming user scoping, so the baseline 3 applies.

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

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

The description states a specific verb and resource ("Возвращает активные карточки пользователя") and pins the filter precisely with "срок которых уже прошёл (строго раньше сегодня)". An agent can tell what it returns, though the description never names the closest sibling (kaiten_today_tasks) to contrast the boundary case.

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 strict-before-today condition implies the use case, but there is no explicit when-to-use, when-not-to-use, or reference to kaiten_today_tasks / kaiten_search_cards as alternatives. The agent must infer routing from the tool name and the filter wording 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?

With no annotations at all, the description carries the full burden, and it does disclose the meaningful behavior: aggregation from the user's cards, the two grouping buckets, the sort keys, and the dual return shape. What it omits is whether the call has any side effects (it appears read-only but never says so) and whether the limit default of 500 can silently truncate a large plan.

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 well-formed sentence that front-loads the action and then enumerates grouping, sorting, and return shape in logical order. No filler or repetition. It is dense but every clause carries 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?

There is no output schema, so the description correctly spends its words describing the return value (markdown text plus structured card list), which is the critical missing piece. Six optional parameters are all covered by the schema. Remaining gaps are the lack of side-effect confirmation and the undefined notion of 'priority' ordering.

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

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

Schema description coverage is 100%, with every one of the six parameters documented in-schema including the role enum and defaults. The description adds nothing about parameters, which is acceptable at this coverage level but means it earns only the baseline. It does not, for example, explain how as_of_date interacts with the 'Overdue'/'Today' buckets.

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 output artifact: builds a day plan from the user's cards, grouped into 'Overdue' and 'Today', sorted by priority and due date, returning markdown plus a structured list. That is much more concrete than a bare 'plan' tool. It stops short of naming sibling tools (kaiten_today_tasks, kaiten_overdue_cards, kaiten_search_cards) that overlap heavily with it, so the agent must infer the distinction.

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 description of what a 'day plan' is, but there is no explicit when-to-use / when-not-to-use statement. Given siblings like kaiten_today_tasks and kaiten_overdue_cards that return overlapping card sets, an explicit 'prefer this over those when you want a combined, formatted view' would have been the highest-value sentence. The agent has to decide between them on its own.

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

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

No annotations are provided, so the description carries the full burden. It implies a destructive mutation ('Удаляет') but says nothing about permanence, required permissions, behavior when the link ID is invalid, or what the response contains. For an irreversible delete with zero annotation coverage this is a substantial gap.

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 zero waste, front-loaded with the action and target. It is efficient, though it is brevity by omission rather than by tight 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 mutation with no annotations and no output schema, the description is too thin: it omits error semantics, irreversibility, and how to obtain the external_link_id. The complete parameter schema is the only thing making it callable at all.

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

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

Schema coverage is 100%, so both card_id and external_link_id are already documented in the schema. The description restates only that the operation is scoped by link ID, adding no format, sourcing, or validity detail beyond the schema — baseline 3 applies.

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

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

States a specific verb and resource: 'Удаляет внешнюю ссылку карточки по ID ссылки' — removes a card's external link by link ID. An agent can tell it apart from add/update external link siblings, though it never names those alternatives or the remove_card_tag sibling 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 prerequisite (e.g., link must exist, card must be accessible), and no mention of alternatives such as kaiten_update_card_external_link or kaiten_list_card_external_links for finding the link ID first. Usage is only implied by the verb.

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

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

No annotations are provided, so the description carries the full burden: it does not say whether the removal requires ownership/admin rights on the card, whether it is reversible, whether the user is notified, or whether a non-member produces an error. For a mutation tool with zero annotation coverage this is a real gap; only the bare mutation intent is conveyed.

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 sentence with no waste, and the action is front-loaded. It is tight rather than padded, though the minimalism shades into under-specification rather than economy.

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

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

A two-parameter destructive membership operation with no annotations and no output schema should say more: post-conditions, error behavior if the user is absent, and whether the card must be open/unarchived. The one-line description leaves the agent without the context needed to call it confidently in edge cases.

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

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

Schema description coverage is 100% – both card_id ('ID карточки') and user_id ('ID пользователя') are documented in the schema. The description maps semantically onto those two parameters but adds no format, range, or sourcing detail beyond them, so the baseline 3 applies.

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

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

States a specific verb ('Удаляет' / removes) and a precise resource ('пользователя из участников карточки' – a user from the card's members). The action is unambiguous and clearly distinct from siblings like kaiten_add_card_member or kaiten_remove_card_tag, though the description itself never names those 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?

No indication of when to use this versus kaiten_add_card_member or other membership-related operations, no prerequisites, and no note about what happens if the user is not currently a member. The agent must infer usage 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?

No annotations are provided, so the description carries the full burden. It states that a tag is removed from a card, but says nothing about whether removal fails when the tag is absent, whether the tag is deleted globally or only detached, whether permissions are required, or whether the change is reversible.

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

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

A single efficient sentence with the action front-loaded and no wasted words. Its brevity, however, contributes to the behavioral 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?

This is a two-parameter mutation tool with no annotations and no output schema, so the description should carry more weight. It does not explain error behavior, side effects, or what the result looks like, leaving the agent with little beyond the schema.

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

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

Schema coverage is 100%, so both card_id and tag_id are already documented in the schema. The description adds the notion that removal is keyed by tag ID but nothing else 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?

The description states a specific verb and resource: removing a tag from a card by tag ID. Its intent is clear and it is naturally distinct from the inverse sibling kaiten_add_card_tag, though it never names that sibling 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 guidance on when to use this tool versus alternatives or on prerequisites. The only usage signal is the implied precondition that the tag must already be attached to the 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?

With no annotations, the description must carry the behavioral burden; it does disclose that the result is an array of cards, and the parameter semantics (no required fields) imply a read operation. But it omits important behavior: default scope (does it search across all spaces?), pagination interplay between limit/offset, result ordering, and any rate limits.

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

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

Four short sentences with purpose front-loaded and zero padding; extra_params guidance sits where it is needed. Slight redundancy between 'все фильтры опциональны' and a schema that already has zero required parameters, but overall tight.

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 17-parameter, no-annotation, no-output-schema search tool, the description covers purpose and the return shape but leaves out scoping defaults and pagination behavior that materially affect correct invocation. Adequate, but not complete for a tool of this 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 100%, so all 17 parameters are documented in the schema itself. The description adds only two pieces of meaning: that filters combine freely, and that extra_params is an escape hatch for unexposed Kaiten API query params. It does not clarify precedence (e.g., archived vs condition=2) or interactions between overlapping filters.

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?

Description opens with a clear verb+resource: flexible card selection by filters, and notes it returns an array of cards. It distinguishes itself from kaiten_get_card (single card) only implicitly; it does not name any sibling such as kaiten_today_tasks or kaiten_overdue_cards, which are also card lists.

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 states that all filters are optional and combinable and directs agents to extra_params for API params not exposed as fields — useful guidance. However it never says when to use this general search instead of the specialized list tools (today_tasks, overdue_cards) or when a scope parameter (board_id/space_id) is required to make results meaningful.

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

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

With no annotations, the description carries the full burden and does well: it discloses filtering rules, the exclusion of done-type columns, the default inclusion of overdue items, and the exact sort order (ASAP first, then due date). It omits permissions, pagination behavior and result shape, but for a read tool the behavioral profile is largely covered.

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: scope, exclusion rule, ordering. The most decision-relevant information (the date window) is front-loaded.

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 seven-parameter read tool with fully documented parameters and no output schema, the description covers the semantics an agent needs to call it correctly. Only the returned card fields remain unstated, a minor gap given the lack of an output schema.

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

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

Schema description coverage is 100%, so every parameter is already documented with its default. The description reinforces the include_overdue default and the meaning of 'today', but adds no syntax or interaction detail (e.g. how role interacts with user_id) beyond the schema, so the baseline applies.

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

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

The description gives a specific verb and resource ('Возвращает активные карточки пользователя') plus a precise scope: due today or earlier, done-type columns excluded. It never names the overlapping siblings (kaiten_overdue_cards, kaiten_search_cards, kaiten_plan_day), so an agent must still infer the distinction, which keeps it 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?

The 'when' is implied by the scoping ('со сроком на сегодня или раньше'), but there are no explicit alternatives — notably kaiten_overdue_cards, which returns a heavily overlapping set, and kaiten_search_cards. The only explicit exclusion is functional (done columns), not a usage 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the partial-update behavior, but for a mutation tool with 11 parameters it does not mention permission requirements, side effects of changing owner/responsible/lane, reversibility, 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 description is two short sentences with no waste, and the core action is front-loaded before the partial-update instruction. Every sentence earns its place.

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

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

This is a mutation tool with 11 parameters, no annotations, and no output schema. The description is too thin for that complexity: it omits what happens to omitted fields, authorization requirements, and the consequences of changing ownership or location fields.

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

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

Schema description coverage is 100%, so all parameters already have field-level documentation. The description adds the useful semantic rule that only fields to be changed should be passed, but it does not supplement per-parameter meaning beyond what the schema provides.

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 clear verb and resource: 'Обновляет поля карточки' (updates card fields). It does not differentiate this tool from sibling mutation tools such as kaiten_move_card, even though the schema includes lane_id, board_id, and column_id fields that overlap with moving 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?

The instruction 'Передавайте только те поля, которые нужно изменить' gives useful partial-update guidance, implying usage for selective field changes. However, it gives no explicit guidance on when to use this tool versus alternatives like kaiten_move_card or kaiten_update_card_external_link, and no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden. The phrase 'и/или' usefully signals that fields can be patched independently, but there is no mention of permissions, behavior when the link or card does not exist, whether omitted fields are preserved, or whether the change is reversible.

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

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

A single front-loaded sentence with no filler. It is efficient, though the extreme brevity is part of why behavioral and usage context is missing.

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

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

A mutation tool with zero annotations, no output schema, and 4 parameters is left with only one sentence. The schema covers field meanings, but nothing tells the agent what the call returns or what happens on a partial update, which is the main risk for an update 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 100% and every parameter already documents itself ('Новый URL', 'Новая подпись', 'ID карточки', 'ID внешней ссылки'). The description's 'и/или' adds a small amount of optionality semantics but does not go beyond the schema's field-level documentation.

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 the resource ('внешней ссылки карточки') and names the mutable fields (URL, подпись). It is clearly distinct from the add/remove/list external-link siblings by virtue of being the update operation, 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?

No guidance on when to use this instead of kaiten_add_card_external_link or kaiten_remove_card_external_link, and no prerequisites such as needing an existing link id. The only implied guidance is that the link must already exist, 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?

No annotations are supplied, so the description carries the whole burden and does not meet it. It never states required permissions, whether omitted fields are left untouched or reset, whether 'checked' sets or toggles the state, or what the response contains — for a mutation tool this is a substantial gap.

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 the verb first and zero filler. Nothing could be trimmed without losing meaning.

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

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

For a 5-parameter mutation with no annotations and no output schema, the description is too thin: it omits the card/checklist/item relationship constraints, permission requirements, and any indication of the result. Only the two optional-field semantics surface.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including the ID hierarchy. The description only restates that text and checked are the mutable ones, adding nothing the schema lacks — the baseline 3 applies.

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

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

States a specific verb ('Изменяет') plus the resource ('пункт чек-листа') and the two mutable aspects (text, checked status). This cleanly separates it from the add/delete checklist-item siblings, though it never names those alternatives 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?

The 'и/или' (and/or) construction signals that partial updates are allowed, which is real usage information. Beyond that the agent must infer that this applies only to existing items and gets no guidance on when to prefer this over delete + re-add, or on any 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?

No annotations are provided, so the description carries the full burden. It does not state whether the edit replaces the entire comment text or merges with it, whether it requires author or admin permissions, whether edits are reversible, or what happens if comment_id belongs to a different card. For a mutation tool with zero annotation coverage, this is a significant gap.

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 zero filler, and the core action is front-loaded. It is not bloated, though its brevity reflects 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 three-parameter mutation tool with no annotations and no output schema, yet the description says nothing about permissions, failure modes, or the shape of the result. Given the complexity of a write operation, it should do considerably more.

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

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

Schema description coverage is 100%, with all three parameters documented in Russian ('Новый текст', 'ID карточки', 'ID комментария'). The description only echoes 'text' and adds no constraint or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: it changes the text of an existing comment. 'Existing' and 'text' implicitly separate it from kaiten_create_comment and kaiten_delete_comment, but it never names those siblings explicitly. The purpose is clear and unambiguous, though differentiation relies on 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 instead of kaiten_create_comment or kaiten_delete_comment, and no prerequisites or context are given. The agent must infer usage entirely from the name and schema.

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