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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the mutation itself; it does not say whether assignment is additive, whether an existing assignee is replaced, whether multiple assignees are allowed, or what validation/permission requirements 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?

The description is a single, front-loaded sentence with no filler; every word contributes to the core action. For a two-parameter tool this is an appropriately sized statement of purpose.

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

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

For a simple two-parameter write operation, the description is minimally sufficient to construct a call: task_id identifies the task and user_id identifies the user. However, it is incomplete on behavioral context (add vs. replace, duplicates, permissions) and does not mention the sibling remove_assignee/list_assignees for contrast, leaving room for hesitation.

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

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

Schema coverage is 0% and the schema only provides names/titles. The description maps 'user' and 'task' to the two parameters only implicitly and gives no operational details such as ID validity, uniqueness, or relationship to existing assignees, so it doesn't compensate for the missing parameter descriptions.

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

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

The description clearly states the action ('assign') and the objects ('a user', 'a task'), so the core purpose is unambiguous and semantically distinct from remove_assignee/list_assignees. It doesn't explicitly name or differentiate 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?

No guidance is given on when to use this tool instead of alternatives, nor any context about prerequisites, exclusions, or ordering relative to other operations. The description implies the obvious use case but provides no explicit usage direction.

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

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

No annotations exist, so the description carries the full burden. It conveys that this is a create operation but discloses nothing else: no mention of return value, idempotency, whether it appends to existing comments, error behavior, or required permissions. This is a mutation tool with zero behavioral context beyond the verb itself.

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 wasted words, and the key action is front-loaded. It is appropriately terse for a simple two-parameter create operation, though one additional clause about the return value or behavior would not have degraded readability.

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 tool with only two required parameters and no nested objects, the description is minimally adequate. However, with no annotations and no output schema, the agent is left guessing about success behavior, return value, and failure conditions — gaps that matter for a write operation.

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

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

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters. It only loosely maps comment and task_id through the phrase 'a comment to a task,' which adds little beyond what the parameter names already imply. No constraints, formats, or edge-case semantics are clarified.

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

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

The description uses a specific verb ('Add') with a clear resource ('a comment') and target ('a task'), making the core purpose unambiguous. It implicitly distinguishes from siblings like update_comment, delete_comment, and list_comments through the verb choice, though it never names them explicitly.

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

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

There is no guidance on when to use this tool versus alternatives. It doesn't contrast with update_comment (modify existing) or list_comments (read), and provides no context about when adding is appropriate.

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

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

No annotations are provided, so the description must disclose behavioral context on its own. It only implies a mutation/association and does not mention idempotency, duplicate handling, error behavior, permissions, or whether the label must pre-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?

The description is a single, front-loaded sentence with no wasted words. It directly communicates the core operation without redundant filler or repetition of the 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?

The tool itself is simple with only two integer parameters and no output schema, so a short description can be adequate. But with no annotations, no parameter descriptions in the schema, and no usage or behavioral guidance, the description only covers the minimum viable information for selecting and invoking the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It maps the two parameters conceptually: task_id refers to the task and label_id refers to the label. However, it does not explicitly describe each parameter's meaning, constraints, or source, leaving the agent to infer the mapping from names.

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

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

The description states the exact action ('Attach') and the resources involved ('a label', 'a task'). This clearly distinguishes it from related siblings like create_label (creating a label definition), remove_label (removing the association), and list_labels (listing available labels).

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 about when to use this tool versus alternatives such as create_label, remove_label, or add_assignee. It does not mention prerequisites like whether the label and task must already exist, or when an agent should prefer a different tool.

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 behavioral disclosure burden. It does well by revealing the symmetric default, directional semantics for asymmetric kinds, permission needs, and the fact that tasks need not be in the same project. It stops short of describing edge cases such as duplicate relations or failure behavior, so a 4 is appropriate.

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

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

The description is compact yet information-dense, with no filler. It front-loads the core purpose, organizes the kinds into a list, then explains direction and access in a clear, structured way.

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 mutation tool with no output schema, the description covers the key inputs, valid values, directionality, permissions, and cross-project behavior. It does not mention return values or error conditions, but these are not essential for selecting or invoking the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains the meaning of task_id versus other_task_id, lists all valid relation kinds, and states the default value for relation_kind. This adds substantial meaning beyond the bare 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 clearly states the action: 'Relate one task to another.' It identifies the resource, the default relation kind, and enumerates the supported relation kinds, making the tool's scope obvious and distinct from siblings like remove_relation.

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 provides useful usage context: it explains defaults, which task is the base versus the other, the role of direction for asymmetric kinds, and access requirements. It does not explicitly contrast this tool with alternatives or state when not to use it, but the practical context is strong.

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

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

With no annotations, the description carries the full behavioral burden, and it excels: it discloses atomicity, the error naming the failed entry, ordering guarantees, the 100-task cap, strict validation that refuses unknown fields, the empty-string date-clearing convention, and the summary-only return format. This goes well beyond what the sparse schema provides.

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

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

The description is front-loaded with the core purpose and then provides dense, non-redundant behavioral and parameter details. Each paragraph earns its place: atomicity, ordering, comparison to create_task, field semantics, limits, and return-value guidance. Nothing is filler.

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

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

Given the tool's moderate complexity and zero annotation coverage, the description is complete: it covers the API requirement, atomic behavior, ordering, validation, batch limit, field semantics, and return type. The output schema likely covers the exact summary shape, so the description's high-level mention of 'summary per created task' is 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 coverage is 0% and the schema only declares project_id and tasks as generic types, so the description must compensate. It does so thoroughly by listing required and optional fields, explaining that entries mirror create_task fields, and warning that unknown keys are refused and dropped keys can silently produce unintended dates or priorities.

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

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

The description opens with 'Create several tasks in one project, in one request,' giving a specific verb and resource while clearly distinguishing it from the single-task create_task sibling. It also states the v2 API requirement and the atomic/ordered batch behavior, so an agent can identify exactly what this tool is for.

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 explicitly contrasts this tool with a loop of create_task calls, explaining that the loop races and can leave partially-created tasks, while bulk_create_tasks is atomic and preserves order. It also directs the agent to get_task when full detail of an individual task is needed, providing clear when-to-use and when-not-to-use guidance.

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

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

With zero annotations, the description carries the full disclosure burden and delivers: partial-update semantics ('Only the fields you pass are written'), a per-project write-access requirement, and an all-or-nothing failure mode ('the whole request is refused and nothing changes'). This goes well beyond generic 'update' language and prevents an agent from assuming partial success or that omitted fields are cleared.

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 paragraphs with the purpose front-loaded in the first sentence. The only mild redundancy is the middle paragraph's three sentences all circling the single point 'this is a partial update on both versions'; informative, but it could be tightened into fewer sentences.

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

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

For a 3-parameter mutation with no annotations and no output schema, the description covers the decision-critical facts: fields affected, partial-update behavior, permissions, and atomic failure. The notable omissions are the response shape (no output schema exists to carry this) and any maximum batch size for task_ids.

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

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

Schema description coverage is 0%, so the description must compensate — and it does by clarifying the key gotcha: only passed fields are written, meaning omitted optional parameters are untouched despite their null defaults. task_ids is also implicitly scoped across multiple projects via the 'every project involved' permission note. It stops short of explaining explicit-null behavior (does done:null clear the field?) or any priority value range.

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 first line names a specific verb ('Set'), the exact writable fields (`done`, `priority`), and the scope ('many tasks in one request'). This clearly differentiates it from siblings like update_task (single task) and bulk_create_tasks (creation), so an agent can route correctly without opening any schemas.

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

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

The description states the tool works 'on either API version' and contrasts its behavior with single-task update, which is a replace on v1 — clear context for when the bulk endpoint is appropriate. However, it never explicitly names sibling alternatives or states when-not-to-use it, so exclusions remain 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 available, the description carries the burden of behavioral disclosure. It does add useful behavior: the column appears at the right-hand end, and a limit caps accepted tasks, with moves into a full column refused. However, it does not mention permissions, success response, irreversibility, or what happens if the limit is omitted beyond the limit semantics.

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

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

The description is short and front-loaded: the first sentence states the core purpose, and the following sentences add necessary behavioral detail. There is no filler or repetition.

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

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

The tool has four parameters, no annotations, and no output schema, so the description needs to provide more contextual grounding. It misses explanation of `view_id` in relation to `project_id`, and it does not describe the return value or expected outcome from a successful call, leaving an agent under-informed for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains the `limit` parameter, and even that is not fully precise about default behavior. `title`, `project_id`, and especially `view_id` are not described, leaving important parameter relationships unexplained.

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

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

The description states a specific action — add a column — with a clear target resource (a project's kanban view). This distinguishes it from sibling tools like delete_bucket, list_buckets, and move_task_to_bucket, so an agent can tell what this tool is for.

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 when to use the tool: when adding a column to a project's kanban view. However, it does not explicitly discuss alternatives, prerequisites, or when not to use it, leaving the routing logic mostly implicit.

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

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

No annotations are present, and the description covers only input formatting (hex_color, Markdown-to-HTML conversion), omitting return value, side effects, permissions, and error behavior. As a mutation tool, more behavioral disclosure is needed.

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

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

The description is very concise and well-structured, using short paragraphs for separate notes. No unnecessary words or redundant 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?

The description covers key input formats and the relationship to add_label, but lacks title expectations, return value, and error handling. Given the simplicity of the tool, it is adequate but not 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 description provides meaningful detail for hex_color and description, including format and conversion behavior, but the required title parameter is not described at all. This is a significant gap for the one mandatory input.

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?

Clearly states the tool creates a label and explains its downstream use by referencing add_label. The action and subject are 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?

Provides some usage context by noting that labels can be attached to tasks with add_label, but does not explain when to prefer this over update_label or delete_label, nor any prerequisites. The guidance is minimal but not misleading.

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 behavioral burden. It does state the core side effect (creates a project) and the parent-child variant, which lets the agent know this is an additive operation. However, it does not disclose auth requirements, error conditions, whether the parent project must exist, or what the tool returns.

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

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

The description is two short sentences with no filler. The main action is front-loaded, and the sub-project guidance follows immediately, making it easy for an agent to parse the essential behavior quickly.

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

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

The description is adequate for basic invocation, especially since the parameter names and schema cover title/description/required details. However, with no annotations, no output schema, and no mention of errors, prerequisites, or return behavior, an agent is left without full context for 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 0%, so the description must compensate. It adds real meaning to parent_project_id by explaining that passing it creates a sub-project. The title and description parameters are self-explanatory from their names, and title is already marked required in the schema.

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

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

The description clearly identifies the action ('Create') and the resource ('a project'), and it adds a specific variant: passing parent_project_id creates a sub-project. It does not explicitly distinguish itself from sibling creation tools like create_task, but the resource name is enough to establish the core purpose.

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

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

The only usage guidance is the conditional for sub-projects: 'Pass parent_project_id to create it as a sub-project.' There is no explicit statement about when to prefer this tool over related tools such as create_task, bulk_create_tasks, or list_projects, nor any exclusions or prerequisites beyond the parent id.

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

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

No annotations are present, so the description carries full responsibility, and it delivers: it warns that percent_done is a fraction and unvalidated, explains start/end versus due_date semantics, and details the reopening behavior of repeat tasks, including the trap that a repeating task with no date can never be closed.

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 dense but waste-free: the opening sentence states the core purpose, and every following paragraph targets a real trap or field ambiguity. Parameter names are formatted clearly and the most important caveats come early.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, the description covers the highest-risk behaviors and field semantics, which is enough for a correct call in most cases. It does not mention the return value of the created task or the meaning of priority, leaving minor but real gaps.

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

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

With 0% schema description coverage, the description compensates by giving concrete semantics for the non-obvious fields: ISO datetime meanings, percent_done as a 0-1 fraction, repeat_after in seconds, and repeat_mode values. Some parameters like priority still lack semantic detail, so the compensation is not complete.

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 first sentence, 'Create a task in a project,' names a specific operation and object, so the purpose is immediately clear. It does not explicitly distinguish this from sibling tools such as bulk_create_tasks or duplicate_task, so it stops short of full sibling differentiation.

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

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

There is no guidance about when to choose create_task over alternatives like bulk_create_tasks or update_task. The intended use is only implied by the name and the opening sentence; no exclusions, prerequisites, or sibling comparisons are provided.

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 disclosure burden. It transparently explains that tasks are moved to the default bucket and left intact, and that the last column cannot be removed. This is strong disclosure of side effects and invariants, though it does not mention permissions or error responses.

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 concise, well-structured, and front-loaded with the primary purpose. The supporting details about task migration and the last-column constraint are directly relevant and add no fluff.

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

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

The description explains the behavioral outcome well but is incomplete for invocation. A caller cannot confidently determine how view_id should be used when multiple kanban views exist, and there is no output schema or annotation to offset this. The tool has only three parameters, so a complete definition should clarify each one or at least explain the view_id relationship.

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

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

Schema description coverage is 0%, and the description does not explain the three parameters. It loosely implies that project_id identifies the project and bucket_id identifies the column, but the optional view_id is completely unexplained. This is a meaningful gap because the distinction between bucket_id and view_id is not obvious.

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

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

The description clearly states a specific action and resource: 'Delete a column from a project's kanban view.' It equates bucket with column, which distinguishes it from other deletion tools like delete_task or delete_label. The behavior is immediately understandable.

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 conveys when to use the tool by defining the delete action and including the constraint that the last column cannot be removed. However, it does not explicitly mention alternatives or when-not-to-use conditions, such as using move_task_to_bucket if tasks should be relocated manually. The guidance is implied rather than direct.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It does disclose that the tool mutates state by deleting a comment, but it does not mention permanence, side effects, or response/error behavior, which are relevant for a deletion 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 core operation in the first and the one essential prerequisite in the second. There is no filler or redundant restatement of the input 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 delete tool with no annotations and no output schema, the invocation contract is incomplete: it does not state what a successful deletion returns or how the task_id should be obtained. The description gives only partial parameter context and no behavioral expectations beyond the act of deletion.

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

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

Schema description coverage is 0%, so the description must compensate for the schema. It adds meaning only for comment_id by directing the agent to list_comments; task_id remains an unexplained integer with no guidance on where it comes from or how it should be formatted.

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 exactly the operation ('Delete a comment') and the resource scope ('from a task'). It naturally distinguishes itself from sibling tools like list_comments, add_comment, and update_comment by naming the destructive variant.

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 first sentence implies when to use it (whenever a comment needs removal), and the second gives a concrete prerequisite ('Get comment_id from list_comments'). However, it does not explicitly discuss when not to use it or compare against alternatives such as update_comment.

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 reveals the key non-obvious behavioral trait — the deletion propagates to every task carrying the label. It does not mention irreversibility or error behavior when the label doesn't exist, but the global-destruction side effect is clearly 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?

Two short sentences with zero waste: the first front-loads the action and scope, the second disambiguates from remove_label. Every clause 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?

For a one-parameter delete tool with no output schema and no annotations, the description covers the essential decision facts: what is deleted, the global scope, and the sibling distinction. Omissions like return value and behavior for nonexistent labels are low-stakes given the tool's simplicity.

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 sole required parameter label_id has 0% schema description coverage and the description adds no explicit explanation of it. The meaning is nevertheless inferable from the parameter's self-explanatory name and integer type, and the description clarifies what effect applying the ID has, so the gap is minor.

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 (delete), resource (a label), and scope ('everywhere... every task that has it'), which precisely defines the operation. It explicitly contrasts itself with the sibling remove_label, so an agent can distinguish them without opening any schema.

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

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

Directly names the alternative (remove_label) and states the selection condition: use this tool when the label itself should be destroyed everywhere, use remove_label when detaching it from just one task. That is explicit when/when-not guidance.

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

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

No annotations are provided, so the description carries full responsibility. It discloses that deletion is cascading, that Vikunja soft-deletes with 30-day retention, that no restore endpoint exists, and that the operation is effectively permanent. This is highly transparent.

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 longer than strictly necessary but each section adds critical warnings: cascading behavior, soft-delete/retention, permanence, confirmation step, and archive alternative. The repetition of 'Checked against' could be trimmed, but overall structure is clear and purposeful.

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

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

Given the single-parameter input and no output schema, the description fully covers the operation's effects, risks, and alternative. It provides enough context for an agent to decide correctly and act safely.

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

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

The schema has only one required integer project_id with no description coverage. The description references confirming the id via list_projects and mentions parent_project_id, but does not explicitly define the project_id parameter beyond its obvious role. Some compensation exists, but it is minimal.

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?

Clearly states the tool deletes a project and cascades to sub-projects, tasks, comments, labels, and assignees. It is distinct from sibling tools like update_project and delete_task, and explicitly contrasts with archiving.

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?

Provides explicit guidance on when to use and when not to use: it advises confirming the ID with list_projects first and directs users to update_project with is_archived: true for non-destructive archiving. This leaves no ambiguity about appropriate invocation.

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 fully carries the behavioral burden. It discloses soft-delete behavior, 30-day retention, the lack of list/restore endpoints, irreversibility, and cascading deletion of comments, labels, and assignees. This is exceptionally transparent.

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

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

The description is front-loaded with the core action and uses every sentence to convey essential risk information. The wording is efficient and memorable without being 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 single-parameter destructive tool with no output schema, the description covers everything an agent needs to call it safely: irreversibility, retention behavior, lack of restore, confirm-id guidance, and cascading effects. Nothing critical is missing.

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

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

Schema coverage is 0% and the description does not explain task_id beyond 'confirm the id first.' That is a safety caution, not parameter semantics. However, the single integer parameter is self-evident from its name, so the lack of explanation is only a minor gap.

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

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

The description opens with 'Delete a task,' a specific verb and resource that clearly distinguishes this from sibling deletion tools like delete_comment, delete_bucket, and delete_label. The scope is unambiguous and immediately understandable.

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

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

The description gives clear operational context: this is irreversible, the id should be confirmed first, and deletion cascades to associated objects. It does not explicitly name an alternative tool, but none is truly relevant for deleting a task, so the guidance is sufficient.

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

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

The description discloses key behaviors: the copy includes specific attributes, lands in the same project, links back with a copiedfrom relation, and returns the copy with the id. It also explains the response envelope handling. However, the final sentence about 'A body without the key is passed through whole' is cryptic and could confuse, slightly reducing transparency.

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 somewhat verbose, including details about response envelopes and a cryptic final sentence. It is structured with a clear lead sentence, but the extra detail about envelope removal and the 'body without the key' clause is redundant and could be trimmed for conciseness.

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 copy operation, the description covers the essential context: what is copied, where it lands, relation created, and response content. It also mentions the alternative for moving. It lacks potential error scenarios or permission requirements, but these are not critical for a basic copy. The response format is partially explained, though the final sentence is unclear.

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 only parameter is task_id, which is clearly the ID of the task to duplicate from context, but the description does not explicitly mention it. With 0% schema coverage, the description should compensate by naming and explaining the parameter; it does not, leaving some inference required.

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

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

The description clearly states the action: 'Copy a task, with its labels, assignees, attachments, and reminders.' It specifies the resource (task) and scope (same project, with copiedfrom relation). It also distinguishes from siblings like move_task, making the purpose unambiguous.

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

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

The description gives explicit guidance on the primary use case and points to an alternative: 'Vikunja offers no way to duplicate straight into another project; call move_task on the copy for that.' This is helpful for when to use this tool versus move_task. However, it does not contrast with create_task or other task creation methods, leaving some room for ambiguity.

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 behavioral context. 'Get' implies a read-only operation and 'full detail' suggests a rich response, which is helpful. But it doesn't disclose auth requirements, not-found behavior, errors, or response shape beyond the vague phrase 'full detail.'

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 first sentence is appropriately concise and front-loaded, but the second sentence 'On v2 the description is Markdown' is extraneous and confusing. It does not help an agent select or invoke the tool, and should be removed.

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 simple single-parameter getter, so the core invocation is clear. However, there is no output schema, no guidance on when to choose this over similar task tools, and no mention of error behavior or what fields 'full detail' actually includes. It is minimally viable 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?

The schema has one required parameter, task_id, with 0% schema description coverage. The description does not explain task_id beyond the schema's own title 'Task Id,' and it doesn't add examples, constraints, or context about how the ID is obtained or used.

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: 'Get a single task with full detail.' This distinguishes it from list/search/update/delete siblings by scope ('single') and depth ('full detail'). However, it doesn't explicitly name a sibling it is not, and the second sentence about v2 Markdown is irrelevant to the tool's purpose.

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: use this tool when you need one task's full details rather than a list of tasks. But there is no explicit 'when to use' or 'when not to use' guidance, and no mention of alternatives like list_tasks or search_tasks.

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 burden of behavioral disclosure. It does not mention whether the operation is read-only, whether it requires authentication, how the assignees are ordered, or what an empty result looks like. For a simple list operation this is a notable 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?

The description is a single short sentence with no wasted words, and the core operation is front-loaded. It is concise and easily parsed, though it sacrifices useful context for brevity.

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

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

Given the tool has an output schema but no annotations and no parameter documentation, the description should clarify the shape of returned assignees and any required prerequisite state (e.g., task must exist). It covers only the basic action, leaving an agent without enough context to anticipate edge cases or correct usage.

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 only parameter, task_id, is an integer and schema coverage is 0%, so the description adds no meaning beyond stating that a task is involved. The schema provides no human-readable description either, but the single parameter and tool name make the semantics fairly inferable; still, the description should have added at least a hint of what task_id must reference.

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 ('List') and a resource ('users assigned to a task'), making the core purpose clear. It does not explicitly differentiate from sibling tools like list_comments or list_buckets, but the focus on assignees is unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives such as search_users or add_assignee. It does not state exclusions or scenarios, leaving the agent to infer usage 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?

The description discloses that 'task_count' may exceed the number of tasks returned due to caps, and suggests using a filter to obtain the remaining tasks. This is a useful behavioral detail about potential pagination or truncation. Since no annotations are provided, this carries the full burden and is reasonably transparent, though it doesn't explicitly state read-only behavior or other side effects.

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

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

The description is short but uses ornate, indirect phrasing ('The whole board', 'thinner question') instead of straightforward language. While it packs useful information, the poetic style detracts from clarity and could be more concise and direct.

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 presence of an output schema reduces the need to describe return values. The description covers the tool's purpose, differentiation from a sibling, and a behavioral nuance (task caps), but it does not explain any parameters or provide broader context such as typical use cases or required permissions. Overall, it is adequate but not comprehensive.

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 schema has zero parameter descriptions, and the description does not explain what 'filter', 'view_id', or 'project_id' mean. It only mentions that 'filter' uses the same syntax as 'list_tasks', but does not elaborate on the others. With no compensation for the complete lack of parameter documentation, this dimension is poorly addressed.

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 clarifies that this tool lists both columns and tasks (unlike 'list_buckets' which only lists columns), and mentions it takes the same arguments as list_buckets. However, the wording is somewhat metaphorical ('The whole board') and could be more direct about the exact resource returned.

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 explicitly distinguishes when to use this tool over 'list_buckets' ('Reach for that one when the tasks are of no interest, and for this one when they are') and advises narrowing results with a 'filter' if task_count exceeds returned tasks, referencing the filter syntax of 'list_tasks'. This provides clear usage guidance relative to 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?

Discloses that only columns are returned (no tasks), board order is preserved, and explains the limit field semantics. With no annotations, this provides good transparency, though it does not address potential errors or permissions.

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

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

Two concise paragraphs, one covering purpose and one covering limit semantics. No redundant content, though the repeated reference to 'list_board' could be tightened.

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?

Provides sufficient context to choose the tool and understand its output compared to list_board. The presence of an output schema mitigates the need to describe return values, but the parameter descriptions are thin.

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

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

Schema coverage is 0%; the description only says 'takes the same arguments' as list_board without explaining project_id or view_id directly. The agent must infer their meaning from sibling context, which is insufficient.

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?

Clearly states it lists the columns of a project's kanban view in board order, and distinguishes itself from list_board by noting it returns columns without tasks.

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

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

Explicitly contrasts with list_board, which returns each column with its tasks, and mentions both take the same arguments, giving the agent clear guidance on when to use each.

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 must carry behavioral disclosure. 'List' clearly conveys a non-mutating read operation, but the description does not mention ordering, pagination, comment scope, or whether deleted comments are included. It is adequate but minimal.

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 front-loaded sentence with no filler. Every word earns its place, and it is appropriately sized for a simple one-parameter listing tool.

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

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

For a one-parameter list tool, the description plus input/output schemas provide a workable baseline. However, it lacks explicit usage guidance and behavioral context such as ordering or pagination, and there are no annotations to compensate.

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 schema has one required integer task_id with no property descriptions (0% coverage). The phrase 'on a task' clarifies that task_id identifies the task whose comments are listed, but the mapping is implicit and no additional formatting or usage detail is provided.

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

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

The description uses a specific verb ('List') and identifies the resource ('comments') and scope ('on a task'). It is clearly the read counterpart to add_comment, update_comment, and delete_comment, though it does not explicitly call out sibling distinctions.

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: the name and description indicate this tool lists comments for a given task, while sibling comment tools cover creation, update, and deletion. However, the description gives no explicit when-to-use or when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the meaning of `bucket_configuration_mode` and the important limitation that in `filter` mode, moving tasks between buckets is unavailable. It also implies read-only behavior through 'List,' though it doesn't explicitly confirm no side effects.

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

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

Each sentence earns its place: the first states the core action and result, the second explains how to chain the output into other tools, and the third clarifies a meaningful behavioral distinction. The structure is clean and front-loaded with the most important 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?

Given the low complexity and the presence of an output schema, the description covers everything an agent needs to call the tool correctly: what it lists, what the ids are for, and the behavioral caveat about `filter` mode. There is no significant missing context.

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

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

Schema description coverage is 0%, so the description must compensate. It does connect the single parameter to the project context ('a project's kanban views'), but it does not explicitly document `project_id` beyond what the schema title already conveys. For a single obvious parameter this is acceptable but not exceptional.

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

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

The description uses a specific verb and resource, 'List a project's kanban views,' and explains that the result includes bucket ids, which is a distinctive return detail. It clearly identifies the tool's role relative to the bucket tools, so an agent can tell this from sibling list tools.

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

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

The description gives explicit guidance on how to use the output: pass an `id` from this tool as `view_id` to the bucket tools. It explains the typical case ('Most projects have one') but does not explicitly state when not to use this tool or name 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 present, so the description carries the full burden. It only states 'List all labels' and adds no information about ordering, pagination, scope (e.g., global vs project), or read-only status beyond the implied 'list.' This is minimal disclosure for a zero-annotation tool.

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

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

The description is three words, perfectly efficient for a parameterless list operation. No redundant or extra sentences.

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 a simple zero-parameter list operation with an output schema present. The description covers the core action, but omits potential nuances like whether this lists labels across all projects or in a specific context (though parameters could not disambiguate). Overall, it is nearly complete for a simple list 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 are zero parameters, so the input schema is fully covered by definition. The description need not add parameter context; the baseline for 0 params is 4.

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 ('List') and resource ('labels'), and explicitly says 'all labels,' making the operation unambiguous. It distinguishes from sibling tools by naming the label resource, which no other sibling 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?

The description provides no guidance on when to use this tool versus alternatives. While there is no other list-labels sibling, it doesn't mention related operations like create_label or add_label, nor any context such as retrieve labels to filter tasks.

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

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

The description discloses the behavior regarding archived projects, the is_archived output field, and the fact that the id is needed for updates. This is transparent about the side effects and data returned, despite lacking annotations.

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

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

The description is concise yet comprehensive, fitting in two sentences without unnecessary fluff. It is well-structured and front-loads the purpose.

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

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

Given the tool's simplicity, the description covers the necessary context: what it lists, how the parameter works, and what the output contains. It is complete enough for an agent to use it correctly.

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

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

The include_archived parameter is fully explained in the description, including its default and effect. The schema provides no additional description, but the tool description covers it entirely.

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 explicitly states the tool lists all projects, uses the verb 'List', and identifies the resource as projects (boards). It also distinguishes from sibling tools like create_project and update_project by focusing on listing.

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 provides clear guidance on the include_archived parameter and explains the default behavior of excluding archived projects, and how to include them. It also notes that archived projects are otherwise unreachable, which informs when to use this tool.

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, and the description does not state whether the operation is read-only or has side effects. The confusing note about bucket_id does not clarify the tool's 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 short but uses poetic and ambiguous language (e.g., 'sits,' 'read any other way is 0') that obscures the meaning. It is not efficiently structured for quick understanding.

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

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

The description does not describe the output schema or response format beyond mentioning 'one entry per kanban view.' No error conditions or edge cases are covered, leaving the agent without essential context.

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 only parameter task_id is not described beyond the schema's title. The description does not explain its meaning, format, or how it is used, leaving the agent to infer from the schema alone.

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

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

The description hints at listing the column (bucket) for a task in each kanban view, but uses vague phrasing like 'Where one task sits' and 'read any other way is 0.' It lacks a clear, direct statement of the operation's purpose.

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 is provided on when to use this tool versus alternatives like list_buckets, list_kanban_views, or move_task_to_bucket. The description does not mention any conditions or precedence.

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 disclosure burden. It adds valuable transparency by explaining that filter and sort_by are applied server-side, that filtering happens before pagination, and that results are complete at any page size. This goes beyond what the schema alone would convey.

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 compact and front-loaded: the one-line purpose comes first, followed by the essential behavioral details and a concrete example. Every sentence earns its place, and there is no redundant 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?

The description covers the key runtime semantics needed to use the tool correctly: server-side filtering, sorting, pagination ordering, and result completeness. An output schema exists, so return-value details are not required. The main gap is lack of explicit guidance on selecting this tool over sibling listing/search tools.

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

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

Schema description coverage is 0%, so the description must compensate. It does so for the two non-obvious parameters, filter and sort_by, with a concrete Vikunja filter/sort example. The remaining parameters (project_id, page, per_page) are self-explanatory from their names and schema defaults, so the coverage is adequate.

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 action and resource: 'List tasks in a project.' It does not explicitly contrast with sibling tools like search_tasks or list_bucket_tasks, but the scope is specific enough that an agent can infer its core purpose without opening the schema.

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

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

The description implies when to use the tool by focusing on project-level task listing and gives concrete examples for filter and sort_by. However, it never explicitly says when to prefer this over search_tasks or list_bucket_tasks, and it does not provide when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that there is no dedicated endpoint, that the operation costs two requests on v1 vs one on v2, and that labels, assignees, comments, relations, dates, and `identifier` are carried over or reassigned. It does not describe response or error behavior, so not a 5.

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

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

Three short paragraphs: purpose and permission, implementation and cost, side effects and identifier reassignment. It is dense, front-loaded, and every sentence adds operational value.

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 two simple parameters are operationally covered well, but with no output schema the description omits what the call returns. It also only mentions write access to the target, saying nothing about whether source-project or task write access is also required. Adequate but with clear gaps for a mutating operation.

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

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

Schema coverage is 0%, but the description compensates by explaining that `project_id` is the writable field whose value performs the move and that the target project needs write access. `task_id` is not elaborated, though its role as the task being moved is clear from context and naming.

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

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

Opens with a specific verb and resource: "Move a task to another project." The implementation note — setting the writable `project_id` is the move — clearly distinguishes it from siblings like `update_task` and `move_task_to_bucket`.

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 first sentence establishes the clear use case, and the write-access prerequisite tells the agent when it can run. It doesn't name alternatives or exclusions, such as using `move_task_to_bucket` for board-level moves, so it stops short of a 5.

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

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

With no annotations, the description carries full behavioral burden. It discloses idempotency ('re-sending the same bucket does nothing'), done-bucket toggling, repeating-task reopening, task-limit refusals, and the project-read-from-task request cost. This is unusually complete disclosure.

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

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

The description is front-loaded with the core action and idempotency note, uses bullet points for side effects, and every sentence adds relevant operational detail. Nothing is 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 mutating kanban operation with no output schema or annotations, it covers action, side effects, mode restrictions, and request-cost behavior. The remaining gap is the role of the optional view_id and expected response/error shape, but the provided context is enough for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It gives useful context about task_id (project is read from the task) and view (manual/filter mode), but it never explains the optional view_id parameter or how it is used, and bucket_id is only implied. The semantics are partially covered, not fully.

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

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

The opening sentence 'Move a task into a kanban bucket' names a specific action and object, and the rest clarifies it is a column move with side effects. It doesn't explicitly contrast with the sibling move_task tool, so it stops short of full sibling differentiation.

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

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

It gives explicit when-to-use guidance: only meaningful when the view's bucket_configuration_mode is manual, and states filter mode is not appropriate. It references list_kanban_views for mapping buckets, but doesn't name alternatives like move_task for other kinds of moves, so not a full 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the primary action but does not mention side effects, error behavior, permissions, reversibility, or whether the operation is idempotent. This is a mutation with no behavioral context beyond the action itself.

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, clear, front-loaded sentence with no wasted words. It communicates the core operation effectively and is appropriately sized for a simple two-parameter tool.

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

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

With no annotations and no output schema, the description leaves important context unaddressed: return behavior, error cases, prerequisites, and how this tool relates to add_assignee or list_assignees. For a mutation tool, this is incomplete guidance for an AI agent.

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

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

Schema description coverage is 0%, and the description does not add meaning to task_id or user_id beyond the obvious parameter names. The phrase 'a user from a task' loosely maps to the parameters, but it does not clarify constraints, relationships, or formats, so the description fails to compensate for the low schema coverage.

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

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

The description uses a specific verb and resource: 'Unassign a user from a task.' This clearly identifies the tool's purpose and distinguishes it from related tools like add_assignee, though it does not explicitly name or differentiate 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?

The usage is implied by the name and description: use this tool when a user should be removed from a task. However, there is no explicit guidance about when not to use it or which sibling tool (e.g., remove_relation, list_assignees) might be more appropriate in a given context.

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 indicates a mutating action, but does not state whether the operation is reversible, what happens if the task or label does not exist, or whether the label definition itself remains intact. The sentence 'Remove a label from a task' gives minimal behavioral detail beyond the operation itself.

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 concise sentence that is appropriately sized for a simple two-parameter mutation. It is front-loaded with the action and object, containing no filler or redundant information.

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

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

For a simple tool with two required integer parameters, the description plus parameter names may be sufficient to form a basic call. However, it lacks any guidance on behavior in edge cases, relationship to add_label, or expected result, so an agent has some gaps to reason through.

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

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

Schema description coverage is 0% and the description does not explicitly explain task_id or label_id. The parameter names are self-explanatory and the description provides some context, but it does not compensate for the missing schema descriptions or clarify IDs, required relationships, or constraints.

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

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

The description uses a specific verb and resource: 'Remove a label from a task.' This clearly distinguishes it from sibling tools like delete_label (removing a label entity) and add_label, and the 'from a task' phrasing removes ambiguity about the operation's scope.

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

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

The description gives no explicit guidance about when to use this tool versus alternatives such as delete_label or remove_assignee. The intended use is only implied by the name and sibling context; there are no exclusions, prerequisites, or alternative routing.

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 by disclosing the non-obvious requirement that the kind must match the original relation. It also points to get_task for verifying current state. It does not mention error behavior or side effects, but for a simple relation removal this is reasonably transparent.

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 with no fluff. The main purpose is front-loaded, and each subsequent sentence adds necessary behavioral or reference information.

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

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

For a simple operation with three parameters and no output schema, the description covers the essential invocation requirements. It tells the agent what to do, what constraint applies, and where to find valid values and current state. Minor gaps like default behavior or error cases are not critical for this tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains the meaning and constraint of relation_kind ('kind has to match... see add_relation for the list') and clarifies the task parameters by describing the operation as between two tasks. The task_id and other_task_id are self-explanatory from names and types.

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

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

The description clearly states 'Remove a relation between two tasks,' which is a specific verb-resource pairing. It is immediately distinguishable from the sibling add_relation, and the second sentence reinforces that distinction by pointing to add_relation.

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

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

The description gives clear context: the relation kind must match the one used at creation, and get_task can be used to inspect current relations. It names both add_relation and get_task as alternative/reference tools, though it does not explicitly state 'use this only when a relation exists.'

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 disclosure burden. It explains that the search spans all visible projects, that every result includes project_id, and that query searches titles and descriptions. It also reveals the important server-side behavior that query and filter cannot be combined. It does not explicitly state 'read-only', but the search semantics make this clear enough.

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 compact, front-loads the core purpose, and uses a short paragraph to clarify when to use it. It then explains parameter semantics and the critical incompatibility without wasted words. Every sentence contributes to correct tool selection or invocation.

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 search tool with an output schema, the description covers what the tool searches, its scope, the key result field, parameter semantics, and a critical usage constraint. It correctly delegates return-value documentation to the output schema. The reference to list_tasks for filter/sort_by syntax is sufficient given that sibling tool exists.

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

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

Schema description coverage is 0%, so the description must compensate. It meaningfully explains query as a text search over titles and descriptions, and clarifies that filter and sort_by reuse list_tasks' server-side syntax. It does not explicitly describe page or per_page, but those are conventional pagination parameters with defaults, and the description adds value on the non-obvious parameters.

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

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

The description opens with a clear verb and resource: 'Search tasks across every project you can see.' It immediately differentiates this from list_tasks by noting list_tasks requires a project and search_tasks is for finding a task when you don't know where it lives. The result reporting project_id further reinforces its distinct purpose.

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 explicitly tells the agent when to use this tool instead of list_tasks, including the exact use case: 'find this task, I do not remember where it lives.' It also provides a clear exclusion, warning that query text search is incompatible with filter and instructing to use one or the other. This gives the agent actionable selection guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what is searched by, not how the search behaves: no mention of partial matching, case sensitivity, result limits, pagination, or multiple matches.

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 filler. It front-loads the action and resource, then adds the use case, making it instantly scannable.

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 search tool with an output schema, the description covers the search semantics and the intended use case. It does not detail result limits or matching rules, but the presence of an output schema lowers the need to explain return values.

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

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

Schema description coverage is 0%, so the description must compensate. It does by clarifying that the single 'query' parameter is matched against 'name or username,' adding real meaning beyond the bare property title.

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

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

The description clearly identifies the resource ('users'), the action ('Search'), and the searchable fields ('name or username'). It also states the practical purpose, 'find a user_id for assignees,' which makes the tool's role unambiguous.

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

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

The phrase 'Use this to find a user_id for assignees' gives an explicit usage context. No alternative user-search sibling exists, so exclusion guidance is less critical, though the description does not explicitly say when not to use this tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states that reminders are replaced, empty list clears them, and no other task fields are affected. It also usefully reveals the v1 vs v2 request-cost difference, which is beyond what the schema conveys.

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

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

The description is compact and front-loaded with the core action, followed by the clear-list behavior and the version-specific request implications. Every sentence adds value without redundancy.

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

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

Despite lacking annotations and an output schema, the description covers the main behavior, side effects, and version-specific costs. It does not mention return values, permissions, or error conditions, but the tool is simple enough that these omissions are minor.

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 input schema only gives names and types, so the description adds essential meaning: reminders must be ISO 8601 datetime strings, the list replaces existing reminders, and an empty array clears them. The task_id parameter is not elaborated, but its purpose is evident from the name and context.

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

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

The description uses a specific verb ('Replace') and resource ('a task's reminders'), and precisely defines behavior including that an empty list clears reminders. This clearly distinguishes it from generic update_task and other sibling tools.

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

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

The description makes the use case clear: modify or clear a task's reminders without changing any other task fields. It does not explicitly name an alternative tool or state when not to use it, but the scope is unambiguous.

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

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

With no annotations provided, the description carries the transparency burden. It discloses full-replacement behavior, the limit reset risk, the refusal when bucket_id is absent from the view, and that position is preserved. This is strong behavioral disclosure, though it does not mention return values or permissions.

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

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

The description is organized into paragraphs and includes useful details, but it is somewhat repetitive and awkwardly phrased, mixing 'column' and 'bucket' terminology. It could be tightened 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?

The description covers key update semantics, limit behavior, read alternatives, and ordering limitations. However, it lacks explicit guidance on how project_id and view_id relate, and does not describe expected return values or error handling beyond one refusal case. Overall adequate but not 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?

Schema coverage is 0%, so the description must explain the parameters. It explicitly explains 'limit' and indirectly explains 'title' and 'bucket_id', but leaves 'project_id' and 'view_id' undefined. Given the low schema coverage, this is insufficient for full parameter understanding.

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

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

The description clearly states the tool's core purpose: renaming a column (bucket) or changing its task limit. This is specific enough to distinguish it from related bucket operations like create, delete, or list.

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

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

The description provides important usage caveats: there is no partial update, a body with only a title resets limit to 0, reads must come from the view's bucket list, and moving a column must be done via the web interface. It does not explicitly name sibling tools, but the guidance is actionable.

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 of behavioral disclosure. It clearly indicates a mutating, replacing action and the need for an existing comment, but it does not disclose return behavior, permissions, or error scenarios.

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 extremely concise: two sentences, no fluff, and the core operation is front-loaded. The follow-up instruction about comment_id adds practical value without redundancy.

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, the description covers the basic operation and ID sourcing but omits return value, auth requirements, and failure behavior. It is adequate for basic invocation but not 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It clarifies where comment_id comes from and implies the comment parameter is the replacement text, but it does not explain task_id's role or provide details on format or constraints.

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

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

The description states a specific action, 'Replace the text of an existing comment,' with a clear resource and scope. This clearly distinguishes it from sibling tools like add_comment and delete_comment.

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 through 'existing comment' and gives the operational hint to obtain comment_id from list_comments. However, it does not explicitly state when to prefer this over related comment tools or mention any exclusions.

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

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

Annotations are absent, so the description carries the full burden. It discloses read-modify-write behavior for v1 and description changes on v2, and notes the extra request cost, but it does not mention idempotency, error handling, or permissions. This is partial but non-trivial transparency.

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 bit wordy, especially the v1/v2 explanation, which is somewhat convoluted and could be clearer. It is structured in three short paragraphs, but the version behavior section reads awkwardly. Overall, it is acceptable but not 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 simple update operation with no output schema, the description covers the core action and some behavioral nuances. However, it omits key details like whether at least one field must be supplied, the meaning of null for title, and any error cases. These gaps make it only moderately 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 schema has no parameter descriptions (coverage 0%). The description adds meaning for hex_color (format and clearing via empty string) and description (Markdown), but leaves title and label_id unexplained, and does not specify how null values behave for title or description. Coverage is about 50%, so it partially compensates.

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

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

The description clearly states 'Update a label' and explicitly clarifies partial update semantics with 'Only the fields you pass change' and the effect on tasks. This distinguishes it from other label operations like create, list, or delete.

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 provides no guidance on when to use this tool versus sibling tools such as create_label, delete_label, or list_labels. It does not mention that it should be used for modifying existing labels and that other tools handle creation/removal.

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

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

The description transparently discloses side effects and edge cases: archiving affects list_projects and editability, unarchiving is required before further edits, re-parenting changes the project hierarchy, and v1 does a full read-write instead of a partial update. Since no annotations are provided, the description fully carries the burden of behavioral disclosure and does so comprehensively.

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 well-structured with clear paragraphs and concise sentences. Every sentence provides necessary information—no fluff or redundancy. The format is easy to parse, with key points (archiving, re-parenting, v1/v2 behavior) highlighted.

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

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

Given the complexity of the tool (partial updates, archiving side effects, version differences), the description is complete. It covers all relevant operational aspects and edge cases. Although no output schema is provided, the description focuses on inputs and their consequences, which is sufficient 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?

Each parameter is semantically explained beyond the schema: 'Only the fields you pass change' clarifies partial update semantics; 'is_archived' archives and unarchives; 'parent_project_id' re-parents; 'hex_color' is six hex digits; 'description' is Markdown. The schema itself has no descriptions, so this added clarity is essential and fully compensates.

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

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

The description clearly states the tool's purpose: 'Update a project. Only the fields you pass change.' The verb 'Update' combined with the resource 'project' is specific and unambiguous, distinguishing it from other update tools for tasks, buckets, comments, and labels.

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 provides thorough usage guidance, explaining partial updates, archiving/unarchiving behavior, re-parenting, and version-specific differences (v1 vs v2). It also mentions the consequence of archiving (projects drop out of list_projects unless include_archived is true) and the associated 412 error, which helps the agent use the tool correctly.

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 full burden. It thoroughly discloses partial-update behavior, v1/v2 differences, field semantics (percent_done is a fraction, repeat modes), response quirks (HTML vs Markdown, 304 unchanged), and validation gaps (Vikunja doesn't validate percent_done). This is exceptionally transparent.

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 long but every sentence carries substantive information. It is front-loaded with the core action and then systematically covers field semantics and edge cases. The structure is logical (partial update, dates, percentages, repeats, response quirks) without redundancy.

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

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

Given the tool's complexity (12 params, 0% schema coverage, no output schema), the description is quite complete. It covers the tricky fields and response nuances but omits some self-explanatory params (title, priority, is_favorite) and does not mention error cases. However, the main risks are well addressed.

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

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

Schema description coverage is 0%, so the description must compensate. It explains due_date, start_date/end_date (ISO 8601, clear via empty string), percent_done (fraction, not percent), repeat_after (seconds) and repeat_mode (0/1/2 meanings). Also covers the done parameter's interaction with repeat. This adds critical meaning beyond the raw schema.

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

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

States a specific verb and resource ('Update a task') and immediately clarifies the partial-update semantics. It differentiates behavior across v1/v2 and explains field-specific effects, making the tool's scope unambiguous even without naming sibling tools.

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

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

Provides clear context for when to call get_task ('when you need it as Markdown') and explains v1 vs v2 behavior that affects usage (extra request vs PATCH). Does not explicitly mention alternatives like bulk_update_tasks, but the guidance is sufficient for common usage decisions.

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