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

With no annotations, the description carries the full burden and does disclose the single most important behavioral trait: the tool refuses to take a task from an existing assignee unless force=true, i.e. an overwrite guard. It is silent on permission requirements, idempotency for already-unassigned tasks, and any response information.

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

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

Two sentences, zero padding, with the core action stated first and the conditional guard second. Nothing is wasted.

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

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

For a 3-parameter mutation tool with no annotations and no output schema, the definition covers the risky path (forced reassignment) but leaves gaps around prerequisites, failure modes, and what the caller gets back. It is adequate but not sufficient on its own.

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

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

Schema description coverage is 100% and the schema already documents id format ('T-007, T-7, 7'), force semantics, and how to unassign ('omit or empty'). The description only restates the force rule, adding no syntax or edge-case detail beyond the schema.

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

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

States a specific verb+resource pair ('Set or clear the assignee of a task') that is distinct from siblings like change_task_status or block_task. It does not, however, differentiate itself from edit_task, which could plausibly also touch the assignee field.

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 its scope (assigning or unassigning) and gives one conditional rule ('unless force=true'), which is useful. But it names no alternatives and no explicit 'do not use this when' guidance, so an agent still has to infer whether edit_task is the better route for changing an assignee.

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

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

No annotations are provided, so the description carries the full burden. It never says whether the call replaces or appends to existing blockers, whether blocker tasks must already exist, whether a blocked task's status changes, whether the operation is idempotent, or what errors look like. For a mutation tool with zero annotation coverage this is a meaningful gap.

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

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

A single front-loaded sentence with no filler; the Jira parenthetical is the one extra clause and it earns its place by clarifying semantics. Nothing is redundant.

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

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

For a two-required-param mutation with no annotations and no output schema, the definition leaves too much unresolved: additive vs. replacement semantics, precondition that blocker tasks exist, and effect on the blocked task's status. It is directionally correct but not sufficient to invoke confidently.

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

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

Schema coverage is 50%: `id` and the blocker items are documented, but the `blockers` array itself is undescribed. The description does not resolve the critical ambiguity of whether `blockers` replaces the existing blocker set or adds to it, nor whether order matters. With half the schema undocumented, the description needed to compensate and does not.

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

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

States a specific verb and resource ('Record that a task is blocked by other tasks') and pins the direction with the Jira parenthetical, which implicitly distinguishes it from the inverse sibling unblock_task. It does not explicitly name siblings, so it falls short of a 5.

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

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

The 'is blocked by' phrasing implies the relationship direction and therefore when to call it rather than unblock_task, but the description never states when to use it, what preconditions exist (blockers must exist?), or that unblock_task removes the link. Usage is only inferable.

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?

Since there are no annotations, the description defines the primary behavioral trait—that it provides a holistic overview of task statuses and sprint progression. This is useful context for a summary function.

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 brief and avoids any superfluous wording, using a single sentence to convey the comprehensive function of the tool.

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

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

The definition is highly complete given the lack of parameters. However, it falls slightly short because it does not provide context on whether this view is read-only or if there are restrictions on the board it summarizes.

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 zero parameters, the description does not need to add semantic meaning beyond what the schema provides. The baseline score for zero parameters is 4, and this description is a single, concise sentence.

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 provides a detailed breakdown of the result ('Board name, task counts per status, and every sprint with its progress'), which clearly defines the scope and content of the function.

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?

While it describes the output, it offers no guidance on when this tool should be used compared to other monitoring tools like check_board or list_tasks, making decision-making for the agent difficult.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation/state transition but does not disclose transition rules, side effects, permissions, reversibility, or what happens to tasks in the sprint when the status changes.

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 is efficient, though its brevity contributes to the missing usage and behavioral context.

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

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

For a mutation tool with no annotations and no output schema, the description is too thin. It should explain transition constraints, valid state changes, side effects, or required permissions, none of which are covered.

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

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

Schema description coverage is 100%, and the input schema already documents both required parameters, including the sprint id format and valid status values with aliases. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Move a sprint to another status.' It clearly identifies a status-transition operation on a sprint, distinguishing it from task-level siblings like change_task_status. However, it does not explicitly contrast itself with other sprint-related siblings such as create_sprint or sprint_add_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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer usage entirely from the name and the simple sentence, which is insufficient given sibling tools like change_task_status and create_sprint.

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 and does well: it discloses two non-obvious side effects (folder move, worklog append) and a pre-condition failure mode with its override flag. It omits permissions requirements, whether transitions are validated or reversible, and what the call returns.

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

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

Two sentences, zero padding. The core action and its side effects come first, with the failure/override caveat second — exactly the right order for an agent scanning for intent and risk.

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

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

For a mutation tool with no annotations and no output schema, the description covers the important behavioral ground: side effects and the blocking guard. Gaps remain around valid status transitions and the return value, but nothing essential to calling it correctly is missing.

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

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

Schema description coverage is 100%, including the status enum values and the id format aliases, so the baseline is 3. The description's mention of force=true restates the schema's 'start even if blocked' rather than adding new semantics, and it says nothing about the optional note parameter.

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

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

States a specific verb and resource ('Move a task to another status') and immediately names two concrete side effects: folder relocation and a worklog entry. It does not explicitly distinguish itself from siblings like start_task or block_task/unblock_task, which overlap with the blocked-task behavior described here.

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 supplies a conditional rule ('Refuses to start a task that is blocked by open tasks unless force=true'), which implies when to use force and when the call will fail. However, it never states when to prefer this tool over start_task, block_task, or unblock_task, leaving the agent to infer routing among siblings.

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

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

With no annotations, the description carries full behavioral burden. It does disclose that fix=true mutates state (repairs stale sprint checklists), which is valuable, but it doesn't say what 'stale checklists' means, whether repairs are destructive, or whether the tool reports findings or errors when issues are found.

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

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

One compact sentence, front-loaded with the validation purpose and ending with the mutation flag. No filler.

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

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

For a minimal one-param tool with no output schema and no annotations, the description is adequate but leaves gaps: the default of fix, what validation failure looks like in the response, and what exactly counts as a stale checklist are all unstated.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema's vague 'repair what can be repaired' by specifying what is fixed: stale sprint checklists, and by making fix=true the trigger for the repair mode.

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: validate consistency between tasks and sprints. It is clearly distinguishable from the CRUD siblings (create_task, change_sprint_status), though it doesn't name the closest read-only alternative like board_summary.

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 with fix=true for repairs, so an agent can infer a check-vs-repair fork. However, it doesn't say when to prefer this over board_summary, whether to check before mutating, or any prerequisites.

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

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

No annotations are provided, so the description carries the burden. It does add real behavioral context that the schema cannot express: comments are human-visible via the web board and are distinct from the worklog. However it does not say whether this mutates task state, whether notifications are triggered, or whether it is idempotent.

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

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

A single tight sentence, front-loaded with the action and resource, followed by the disambiguation and the visibility note. No filler.

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

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

For a simple two-parameter add-note tool with no annotations and no output schema, the description covers what the tool does, where the output surfaces (web board), and the closest alternative. Only the mutation/notification semantics are left implicit, which is a minor gap for a low-complexity 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 100%, so both parameters (id with accepted formats, message as Markdown) are already fully documented. The description adds no additional parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource ("Add to the task's discussion") and immediately draws a boundary against the sibling log_work with "separate from the worklog." An agent can tell it apart from log_work without opening either schema.

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

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

Gives concrete use cases (ask a human a question, leave a review note, answer one) and names the alternative it is not (the worklog). It stops short of explicit exclusions or prerequisites such as whether the task must be open, so it is clear context rather than full 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 the full behavioral burden. It implies a write operation but discloses nothing about permissions, whether omitted fields get defaults, whether title collisions fail, or whether the new sprint is returned.

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 three-word fragment with no waste but also no useful front-loading. Brevity here reflects under-specification rather than efficient communication for a six-parameter mutation 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?

A mutation tool with six parameters, no annotations, and no output schema needs the description to cover behavior and return expectations. The fully documented schema helps, but the description leaves the agent without any operational 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 100% -- every parameter, including date formats and the status alias list, is already documented in the schema. The description adds nothing, so the baseline 3 applies.

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

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

"Create a sprint" restates the tool name almost verbatim and adds no distinguishing detail. It does convey the verb (create) and resource (sprint), but nothing separates it from siblings like create_task or list_sprints beyond the obvious noun.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_sprints or change_sprint_status. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns the new task and allocates its id automatically, which is valuable because there is no output schema. However, it does not mention permissions, validation behavior, defaults for omitted fields, or other side effects of creating a task.

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 wasted text. The purpose is front-loaded, and the return/id behavior is stated immediately after. Every sentence earns its place.

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

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

The schema fully documents the 8 parameters, and the description partially compensates for the missing output schema by saying the new task is returned with an automatically allocated id. It remains incomplete on default field behavior, creation side effects, and permissions, which matters for a mutation tool with no annotations.

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

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

Schema description coverage is 100%, so all 8 parameters are already well documented, including the enum for priority and accepted status aliases. The description adds no parameter-level detail beyond the schema. A baseline score of 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: "Create a task." This clearly differentiates the core operation from siblings like edit_task, list_tasks, get_task, and change_task_status. It does not explicitly contrast itself with adjacent creation or mutation tools, so it earns 4 rather than 5.

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

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

The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The operation is implied by the name, but there is no explicit usage 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?

With no annotations, the description carries the full burden; it usefully discloses PATCH-style partial-update behavior and the empty-string sentinel for detaching a sprint. It says nothing about permissions, whether label/blocker replacement is destructive, or what the call returns, which leaves significant gaps for a mutation tool with zero annotation coverage.

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

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

Two short clauses, front-loaded with the core action and followed by the two most consequential behaviors. Every word earns its place with no 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?

Six parameters, no output schema and no annotations mean the description should do more; it omits return value, error behavior on unknown ids, and whether replacement of labels or blockers is reversible. The high schema coverage covers field-level meaning, so it is adequate but not complete.

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

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

Schema coverage is high (83%), so the baseline is 3, but the description adds genuine meaning the schema lacks: that omitted fields are untouched and that sprint='' is the detach sentinel. It does not clarify the id aliasing or the replace-all nature of blocked_by, but it improves on the schema for the least obvious parameter.

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

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

"Change task metadata" gives a specific verb plus resource, and "metadata" implicitly excludes status changes, which sibling tools like change_task_status, assign_task, and rank_task handle. However, no sibling is named, and the block/unblock siblings overlap conceptually with the blocked_by parameter, so the boundary requires inference.

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?

"Only the fields given are changed" establishes partial-update semantics and "sprint='' detaches" gives one concrete usage recipe, so usage is implied. There is no explicit statement of when to prefer this over block_task/unblock_task or change_task_status, and no prerequisites are mentioned.

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

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

No annotations exist, so the description carries the full burden. It hints that the response bundles sprint metadata, progress metrics, and tasks, but says nothing about read-only safety, authorization needs, error behavior for unknown ids, or whether task lists are paginated/truncated.

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

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

A single short phrase with no padding. It is front-loaded and efficient, though it reads as a noun fragment rather than a sentence, which slightly weakens immediate comprehension.

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 should explain the shape of the returned data (what 'progress' means, whether tasks are full objects) and confirm read-only behavior. As written, an agent knows only the broad categories of the response.

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

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

Schema coverage is 100% with the 'id' parameter documented as 'sprint id such as S-001'. The description adds no meaning beyond the schema, so the baseline 3 applies rather than a higher score.

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 fragment 'Sprint details, progress, and its tasks' names the resource and roughly what it returns, but gives no verb (retrieve/fetch) and no scope distinction from siblings like list_sprints or board_summary. An agent can guess it's a read of a single sprint, but the purpose is implied rather than stated.

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

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

No indication of when to call this versus list_sprints (enumerate sprints) or board_summary (aggregate view). There are no exclusions, prerequisites, or alternative routing, so the agent must infer selection from the name alone.

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

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

No annotations exist, so the description carries the full burden; it does disclose what the response contains (metadata, brief, worklog, comments), which is genuinely useful read semantics. It says nothing about permissions, error behavior for unknown ids, or pagination of worklog/comments.

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

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

One dense sentence with zero filler, and the most important information (what the payload contains) is front-loaded before the usage hint.

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

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

With no output schema and no annotations, the description adequately defines the returned payload's composition for a single-parameter read tool. It falls short only on failure modes and whether worklog/comments are truncated.

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?

Single id parameter with 100% schema description coverage including the T-7/7 normalization rule, so the schema fully documents it. The description adds no additional parameter meaning, which is the expected baseline when coverage is 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?

States a specific resource and enumerates its parts: metadata, Markdown brief, worklog entries, and comments. That content list implicitly separates it from list_tasks (summary listing) and get_sprint (different resource), though no sibling is named explicitly.

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

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

The parenthetical 'check it for answers and review notes' implies a usage pattern — read this to find human replies on a task — but there is no explicit statement of when to prefer it over list_tasks or comment_task, and no exclusions.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read operation but says nothing about pagination, ordering, what 'progress' contains, or whether results are filtered by the caller's workspace — all material for a list tool.

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

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

A single five-word sentence with zero filler, and the verb is front-loaded. It is efficient, though its terseness is the source of the coverage gaps rather than a model of tight writing.

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

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

With no annotations and no output schema, the description must explain what is returned. 'Progress' is left undefined and nothing indicates whether all sprints are returned or how status filtering behaves (inclusive, default to all), leaving the agent guessing about result shape.

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

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

Schema coverage is 100%: the single optional 'status' parameter already documents its enum values and accepted aliases ('wip', 'todo', 'closed'). The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb+resource ('List sprints') plus a vague return qualifier ('with progress'). It is enough to tell this apart from get_sprint or create_sprint by name alone, but 'progress' is never defined and no sibling is explicitly referenced.

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

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

There is no guidance on when to use this versus get_sprint (single sprint detail) or board_summary (aggregate view). The agent must infer that this is the enumeration path from the name and the sole optional status filter.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses ordering, that results are metadata only, and that each task carries blocked_by, blocked, and blockers, including the meaning of blocked. It does not mention pagination or permissions, but the core behavior is 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, front-loaded with the core purpose and ordering rule. Each sentence adds distinct value: usage, alternative tool, and returned blocking fields.

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 read-only list tool with no output schema, the description supplies the ordering semantics, metadata-only scope, alternative tool for details, and the key blocking-related return fields. Combined with the fully documented input schema, an agent has enough context to call it correctly.

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

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

Schema description coverage is 100%, so all six filter parameters are fully documented in the schema. The description adds no filter-specific meaning beyond the schema, which is acceptable given the high coverage baseline.

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

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

The description states a specific verb and resource ('List tasks') and immediately clarifies the ordering ('queue order: the top of the queue first'). It explicitly distinguishes this metadata-only listing from the sibling tool get_task, which provides the brief and worklog.

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

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

It gives clear operational guidance ('take work from the start of the list') and routes the agent to get_task when full details are needed. It does not explicitly discuss when to use each filter or when not to use the tool, but the primary usage context and alternative are clear.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral trait that this appends rather than replaces existing log content, and that content is Markdown, but it says nothing about whether the task must exist, error behavior, or what the call returns.

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

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

Two short sentences, zero waste, with the core action front-loaded before the usage hint.

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

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

For a two-parameter append tool with no output schema and no annotations, the description covers the action, the content format, and typical use cases. Only the return value and failure modes are unaddressed, which is a minor gap at this complexity.

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

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

Schema description coverage is 100%, so both id and message are already documented, including id format variants. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Append an entry to the task's worklog.' That is clearly distinct from status-changing siblings like change_task_status, though it never explicitly contrasts with the very similar comment_task.

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

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

'Use it for progress, decisions, blockers' gives implied usage context, but there is no explicit when-not guidance and no mention of the near-identical sibling comment_task, leaving the agent to guess which of the two to pick.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the meaningful consequence of the operation — rank drives list/board-column sort order and defines what agents pull first — which is real value beyond a bare 'update' verb. However, it says nothing about required permissions, what happens on invalid id or on concurrent rank changes, or what the call returns, which for an unannotated mutation 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?

Two short sentences, both front-loaded: the operation first, then the argument contract, then the downstream effect. Nothing is repeated from the schema and no sentence is wasted.

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

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

For a five-parameter mutation with no output schema, the description covers the essential semantics: what changes, how the new order is expressed, and why order matters. The remaining gap is failure/edge behavior (missing or conflicting positional argument, unknown id), which an agent would have to discover by trial.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds a genuine semantic rule the schema does not encode: top, bottom, before and after are mutually exclusive and exactly one is expected. That constraint materially changes how an agent composes the call and is not inferable from the flat property list.

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 ('Reorder the queue'), anchors it to a known concept (Jira: Rank), and describes the observable effect — lists and board columns sort by rank. No sibling tool performs reordering, and the mention of queue/list/board ordering makes the scope unmistakable.

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 constraint 'Give exactly one of top, bottom, before or after' is a clear invocation rule an agent must follow, and 'agents take work from the top' explains why top matters. It lacks an explicit when-not statement (e.g. what happens if no positional argument is supplied, or when to prefer top over before), but there is no competing sibling to route away from.

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 behavioral burden, yet it says nothing about idempotency, what happens to tasks already in another sprint, whether the operation is atomic across the task array, or what errors arise for invalid task ids. For a mutation tool this is a substantial gap.

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

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

A single front-loaded sentence with zero waste, but its brevity reflects under-specification rather than disciplined economy—there is room to add essential context without bloat.

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

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

With no annotations, no output schema, and only partial parameter documentation, the description leaves an agent without enough information to invoke a bulk mutation safely. It should at minimum explain the effect on already-attached tasks and the failure modes.

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

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

Schema coverage is only 50%, and the description adds no meaning beyond the schema's own hints ('task id such as T-007', 'sprint id such as S-001'). It does not explain whether multiple tasks may span sprints, ordering effects, or limits on the array size.

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 ('attach') and resource ('tasks to a sprint'), which is unambiguous and clearly distinct from the removal sibling sprint_remove_tasks. It stops short of naming alternatives, but the action itself is clear.

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

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

No indication of when to use this versus sprint_remove_tasks or create_sprint, and no prerequisites such as whether tasks must be unassigned first or belong to a specific project. The agent must infer everything from the name.

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

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

No annotations are provided, so the description carries the full burden. 'Detach' implies the tasks survive and only the sprint association is removed, but the description doesn't say whether task status/board position changes, whether the operation is reversible, or whether it fails on tasks not in the sprint.

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

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

A single front-loaded sentence with zero waste, but for a batch mutation tool it is undersized rather than appropriately concise — the terseness comes at the cost of behavioral detail an agent needs.

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

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

With no annotations, no output schema, and an unelaborated mutation, the description leaves the agent guessing about side effects (bulk partial failure, status changes, reversibility). For a 2-required-param write operation, substantially more context is warranted.

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

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

Schema coverage is only 50%, and the description adds nothing about either parameter. It doesn't mention that multiple tasks can be detached in one call, whether unknown IDs cause partial failure, or what 'sprint' should be when the sprint is at capacity/closed.

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?

'Detach tasks from a sprint' states a specific verb (detach) and resource (tasks/sprint), and the antonym relationship with the sibling sprint_add_tasks makes the distinction obvious without naming it. It stops short of a 5 because it never explicitly routes against that sibling or clarifies the effect on the tasks themselves.

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

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

There is no guidance on when to use this versus sprint_add_tasks, change_sprint_status, or edit_task, and no stated prerequisites (e.g., sprint must be active, task must currently be in the sprint). The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden and does well: it discloses atomicity, assignment/claim behavior, and the three failure preconditions. However, it does not explain what the force parameter actually overrides, nor whether permissions or workflow rules can also cause failure.

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 tightly written sentences. The core action and atomicity are front-loaded, followed by failure conditions and the sibling-tool routing advice, with no wasted text.

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

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

For a no-annotation mutation tool, it covers purpose, side effect, failure modes, and alternatives well. The main remaining gap is the exact semantics of force and whether it can bypass all stated failure conditions.

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

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

Schema coverage is 100%, so the baseline is 3. The description clarifies the id parameter's role and the atomic claim/transition behavior, but adds no meaning for force beyond the schema's terse 'take it anyway'.

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 compound action: claim a backlog task and move it to in-progress atomically. It explicitly distinguishes itself from the assign_task + change_task_status combination and names the Jira equivalent.

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 says to use this instead of assign_task + change_task_status when several agents share a board. Also states the precise failure conditions where the tool should not succeed, giving 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 no annotations provided, the description carries the full burden of behavioral disclosure for a mutation tool. It does not say whether the blocker tasks themselves are deleted or merely the dependency edge removed, whether the operation is reversible, or what happens if a listed blocker isn't actually blocking.

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

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

A single short sentence with no filler and the action front-loaded. It is efficient, though its brevity comes at the cost of the missing details noted elsewhere rather than 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 two-required-parameter mutation tool with no annotations and no output schema, the description omits error behavior, idempotency, and the meaning of the blockers argument. It is not sufficient to call the tool confidently in edge cases.

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

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

Schema description coverage is 50%: the id property is documented with an accepted-id format, but the blockers array itself has no schema description. The description only echoes that blockers are removed and adds no semantics such as whether existing non-blockers cause errors or how partial failures are handled.

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

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

Names a specific verb (remove) and resource (blockers on a task), which reads as the inverse of the sibling block_task. It does not explicitly differentiate itself from block_task or any other sibling, and leaves slightly open whether 'blockers' means blocker tasks or blocking relationships.

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

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

There is no statement of when to use this versus alternatives, no mention of the counterpart block_task, and no preconditions (e.g., blockers must currently exist). The agent must infer usage entirely from the name.

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