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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-non-destructive profile is covered. The description adds a meaningful behavioral constraint — the three-level hierarchy cap — but says nothing about permissions, failure modes when the parent doesn't exist, 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?

A single front-loaded sentence with zero waste; the hierarchy constraint is packed into parentheses rather than padded into extra clauses.

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 creation tool with no output schema and minimal annotations, the description covers purpose and placement limits but omits what comes back — the newly created task id — which an agent needs to chain into tasks_link, tasks_move, or tasks_set_status. It also doesn't mention how the 'after' dependency interacts with creation. Adequate but with a clear gap.

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

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

Schema coverage is 100%, so every parameter including 'parent' is documented in the schema itself. The description restates the parent parameter's semantics but contributes no additional format or edge-case detail, making this the expected baseline 3.

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 ('Add a task') and clarifies both placement modes (under a sprint id or a task id). The depth constraint 'sprint > task > subtask' further scopes it and implicitly separates it from tasks_add_sprint, 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 description clearly establishes when this tool applies (creating a task/subtask under an existing parent) and encodes the max-depth rule as a usage constraint. It stops short of naming alternatives such as tasks_add_sprint for creating sprints, so the agent must infer that 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description contributes nothing further: no note on required permissions, whether duplicate titles are allowed, whether start/end are mandatory in practice, or what happens to existing sprints. For a mutation tool it leaves all behavioral context to the schema.

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

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

The single sentence is short and front-loaded but is under-specified rather than concise; it carries no information an agent could not get from the tool name. Brevity here reflects missing content, not economy.

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

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

With four parameters and no output schema, the description should at least indicate the parent context of the new sprint and any constraints linking start and end dates. None of that is present, so an agent must guess at invocation 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%, so title, goal, start and end (including the YYYY-MM-DD format) are already documented in the schema. The description adds no meaning beyond that, which is the expected baseline when the schema does the work.

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

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

"Create a sprint" restates the tool name (tasks_add_sprint) almost verbatim and adds no specificity about scope, such as which project or workspace the sprint belongs to. An agent cannot distinguish it from the sprint-related sibling tasks_sprint based on this text alone.

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

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

There is no statement of when to use this tool versus tasks_sprint, tasks_add, or tasks_edit, and no prerequisites (e.g., whether a project/board must already exist) are mentioned. Usage is only implied by the verb "Create."

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 readOnlyHint already declares that this is a safe read operation. The description adds meaningful behavioral context by specifying exactly what information the bundle contains, which is important because no output schema exists. It does not discuss size, performance, or failure 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?

A single sentence front-loads the purpose and then lists the bundle contents efficiently. There is no redundant or filler 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?

Because there is no output schema, the description must explain the return contents, and it does so by enumerating the bundle fields. It is nearly complete for a one-parameter read-only tool, though it could better situate itself among the many sibling task-inspection 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?

There is only one parameter, and the input schema fully documents it with examples ('1', '1.2', '1.2.3') at 100% coverage. The description adds no additional parameter meaning beyond the schema, which is the expected baseline when schema coverage is high.

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 concrete resource and enumerates the bundle contents (description, dependencies with merge commits, spec link, notes, changed files), so an agent knows what this tool returns. It does not differentiate from siblings such as tasks_show or tasks_view, which keeps it from a 5.

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

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

The phrase 'for one item' implies single-item usage but gives no explicit when-to-use guidance, prerequisites, or comparison with alternatives like tasks_show or tasks_list. The agent must infer when this richer bundle is preferable.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that – '--after replaces the list; empty clears' and the rejection rule for multi-id title edits – but says nothing about permissions or what existing values are touched.

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 dense sentences with zero filler, and the constraint about id vs ids is front-loaded. The parenthetical sprint-only clause is slightly compressed but still readable.

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

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

For a 9-parameter mutation tool with no output schema, the description covers field scope and the key invocation constraint, and annotations handle safety. It leaves return behavior unaddressed, which is a minor gap given no output schema 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 coverage is 100%, so every parameter is already documented and the baseline is 3. The description reinforces the replace/clear semantics of 'after' and the mutually exclusive id/ids rule, but much of that is already stated in the schema, so the marginal value is modest.

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

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

The description names a specific verb (edit) plus the exact fields it can mutate (title, description, assignee, dependencies, and sprint goal/start/end), which clearly separates it from status/move/link siblings. It stops short of explicitly naming an alternative, but the field enumeration leaves little ambiguity about what this tool does.

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

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

It gives hard invocation constraints ('Pass either id or ids (exactly one)', '--title with multiple ids is rejected'), which is stronger than implied usage. However, it never says when to reach for tasks_set_status, tasks_move, or tasks_link instead of editing fields here, so routing guidance is only partial.

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

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

Annotations already declare the write-with-idempotency, non-destructive profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds nothing beyond that: it does not say what happens when the same kind is attached twice (overwrite vs. duplicate), which is exactly the behavior the idempotent hint implies but doesn't explain.

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. Slightly redundant with the schema enum, but it costs almost nothing and orients the agent immediately.

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 simple three-parameter tool with no output schema, so not much is required. Still missing: overwrite semantics for repeated kinds, and any gloss on the opaque enum values 'fixes' and 'scope', which an agent could easily misuse.

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 per-field descriptions and a full enum, so the schema carries parameter meaning. The description only restates the enum values, and gives no hint about ambiguous kinds such as 'fixes' or 'scope' or what value formats each expects.

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

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

Specific verb+resource: 'Attach a structured link ... to an item', and it enumerates the link kinds inline. The verb 'attach' cleanly contrasts with the sibling tasks_unlink, though it never names that sibling explicitly.

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

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

Usage is only implied by the verb 'attach' and the presence of tasks_unlink as a counterpart. There is no statement of when to use this versus tasks_edit or tasks_note, nor any prerequisite about the item needing to exist.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds real value by disclosing the return shape (indented tree) and that status is derived rather than stored, but it says nothing about default scope when no filters are given, pagination, or ordering.

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 compact sentence with the key information (scope, tree format, derived status) front-loaded. No filler, though it is arguably too terse given 8 parameters.

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 listing tool with no output schema, the description covers the output shape but omits default behavior (does it list everything when called with no arguments?), ordering, and how filters combine. The rich schema compensates for the parameter side, but output expectations remain 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 100% across all 8 parameters, so the schema already explains each filter. The description adds only the general idea of hierarchy and derived status, no per-parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (List), the resources (sprints/tasks/subtasks) and the output shape (indented tree with derived status), which is more informative than a bare 'list tasks'. It does not distinguish itself from close siblings like tasks_overview, tasks_brief or tasks_view, 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?

There is no guidance on when to use this tool versus tasks_overview, tasks_next, tasks_sprint or tasks_brief. An agent must infer the use case from the name alone.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds that output is a printed log and can be scoped by item or timestamp, but says nothing about ordering, volume, truncation, or what each log entry contains — useful gaps for a log tool with no output schema.

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

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

A single front-loaded sentence with the resource stated first and the two optionality notes parenthesized after it. No padding, though the extreme terseness leaves no room for the routing context an agent would want.

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?

Two optional parameters and an annotation mean the description doesn't need to carry much, but for a log-retrieval tool it omits scope defaults (all items when id is absent), ordering, and rough output shape. Adequate to invoke, not enough to predict the result.

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

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

Schema coverage is 100%, so both id (with its sprint/task/subtask format) and since (ISO timestamp) are fully documented in the schema. The description restates them at a high level but adds no format or filtering semantics beyond what the schema already gives. 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?

Specific verb ("Print") plus resource ("audit log") makes the operation immediately identifiable and distinguishes it from list/show/stats siblings by resource type. It stops short of explicitly naming which sibling to use alternatively, so it is clear but not sibling-differentiated at the top level.

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 describes parameter options, not when to choose this tool over tasks_show or tasks_stats. There is no statement of when an audit log is preferable to inspecting an item directly, and no exclusions or prerequisites.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds real value beyond them by disclosing the subtree renumbering side effect and the full failure surface (unknown ids, sprints, self-subtree, MAX_DEPTH, same-parent without pos). It does not say what the caller gets back or whether renumbering breaks existing id references, which keeps it below 5.

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

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

Two compact clauses, with the action front-loaded and the error surface parenthetically packed. It is efficient, but the dense shorthand ('same parent without --pos') costs a little readability for an agent parsing the parameter name.

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

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

For a 3-parameter mutation with no output schema and only coarse annotations, the description covers the effective action, its side effect on ids, and the error conditions an agent must avoid. The main omission is what the tool returns (e.g. new id/path) and any permission or ordering caveats.

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 id, new_parent and pos are already documented in the schema; baseline 3 applies. The description only contributes the same-parent-without-pos constraint, and the '--pos' notation reads like a CLI flag rather than the 'pos' parameter name, adding mild ambiguity rather than clarity.

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 an item to another parent") and adds the key side effect that the subtree is renumbered. It does not differentiate itself from the sibling tasks_mv, which is likely the closest alternative, so it stops short of a 5.

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

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

The parenthetical error list implies the preconditions (valid ids, non-sprint item, parent not inside own subtree, depth limit), which is useful implicit guidance. However, there is no explicit 'use this instead of tasks_mv when...' routing, and the sibling set contains an obviously overlapping tool that is never 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is known. The description adds genuine value by disclosing that the subtree is renumbered, a non-obvious side effect. It still omits what happens to displaced siblings, failure modes, and whether the move is reversible.

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

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

A single short sentence that front-loads the action and appends the key caveat in parentheses. No waste, nothing redundant with the schema or annotations.

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

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

For a 3-parameter mutation with annotations and full schema coverage, the definition is minimally viable: the renumbering side effect is covered. It falls short on sibling differentiation (tasks_move) and on error/edge-case behavior for a tree-restructuring operation, which matters 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 coverage is 100%, including the dotted-id convention and the 1-based 'pos' with append default, so the schema carries the parameter burden. The description's 'renumbers the subtree' hints that 'pos' shifts sibling positions but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Move an item to another parent') plus the scope of side effects ('renumbers the subtree'). It does not distinguish itself from the sibling 'tasks_move', which an agent could easily confuse with this one given the near-identical name.

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

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

There is no guidance on when to use this versus the many siblings, most notably tasks_move and tasks_edit, which overlap in intent. No prerequisites, no exclusions (e.g., moving an item under its own descendant), nothing to route the agent.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context such as dependency readiness, leaf-item filtering, and first-unfinished-sprint scoping, but it does not describe ordering, return shape, or edge cases.

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 immediately communicates the key scoping criteria before any implied usage.

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 read-only tool with two optional, fully documented parameters, the description covers the core selection logic well. However, with no output schema, it could say more about the returned item shape or ordering, which leaves a modest gap.

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

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

Schema description coverage is 100%, so both optional parameters (count and assignee) are fully documented in the schema. The description adds no additional parameter semantics, which is acceptable given the complete schema coverage, 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 specifies the exact selection criteria: next ready, unfinished leaf items with dependencies met, in the first unfinished sprint. This clearly distinguishes it from broader listing siblings like tasks_list and tasks_sprint, though it does not explicitly name alternatives.

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

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

The selection criteria imply when to use this tool — when the agent needs the next actionable item from the first unfinished sprint. However, there is no explicit guidance on when to choose this over tasks_list, tasks_sprint, or tasks_brief, nor 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 already declare this is a non-destructive mutation. The description adds that notes are appended and dated, which is useful behavioral context, but it does not describe return behavior, idempotency, or what happens to prior notes.

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 the action front-loaded and zero wasted words. The parenthetical examples are compact and informative.

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 note-append tool with full schema coverage and non-destructive annotations, the description is nearly complete. A minor gap is that it does not mention confirmation or return behavior, though no output schema exists requiring that detail.

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 are already documented. The description adds examples of note content, but it does not add syntax or format details beyond the schema's 'Note text' and 'Item id' definitions.

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: 'Append a dated note to an item,' with examples of note content. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like tasks_log or tasks_edit.

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 examples (progress, decisions, pointers to patches) give clear context for when to use this tool. There is no explicit when-not guidance or named alternative, but the intended use is evident.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is lighter. It does add genuinely non-obvious context in the word 'derived' — status is computed rather than stored — but says nothing about ordering, scope, or whether closed sprints are included.

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 fragment with zero filler — the payload contents come first and nothing is repeated. It is telegraphic rather than a complete sentence, which is efficient but slightly terse even for an overview 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 output schema and no parameters, the description carries the full burden of explaining the return value, and it only partially does so: it lists derived status, counts, and goal but not the item shape or whether sprints include task breakdowns. Adequate to select the tool, thin for predicting its output.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly signals a zero-argument, whole-collection call.

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 resource (all sprints) and the concrete payload it returns: derived status, per-status counts, and the goal. That distinguishes it from single-sprint tools like tasks_sprint, but it never explicitly positions itself against tasks_stats or tasks_list, so the differentiation is inferred rather than stated.

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

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

The phrase 'in one call' implies this is a bulk overview rather than per-sprint retrieval, which hints at when to prefer it. However, there is no explicit when-to-use rule and no named alternative among the 18 siblings, so the agent must infer the boundary itself.

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

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

Beyond annotations marking the tool as destructive, the description discloses cascade behavior, refusal when dependents exist, and the preview/confirm safety flow. This is substantial behavioral context 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?

Three compact sentences, front-loaded with the destructive scope, then the refusal condition, then the confirm workflow. 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?

For a destructive delete operation with annotations covering safety traits, the description supplies the cascade scope, dependency refusal, and two-step confirm procedure. No output schema exists, and the preview behavior is sufficiently signaled 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 100%, so the id and confirm parameters are already fully documented. The description reinforces confirm as the preview/commit switch but adds little parameter detail beyond what the schema provides.

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

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

The description states a specific verb and resource: delete an item, including everything below it. The cascade scope to notes and dependencies makes the operation distinct from sibling task tools such as tasks_unlink or tasks_set_status.

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

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

It explains the two-step preview/confirm workflow and the precondition that deletion is refused while other items depend on the item. It does not explicitly name alternative tools or tell the agent to unlink dependents first, but the operational context is clear.

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

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

Annotations already declare this is not read-only, is idempotent, and is not destructive. The description adds meaningful behavioral context beyond annotations: parent statuses are derived automatically, blocking requires a reason, and cascade_down applies the status to all leaves below a task or sprint. It does not cover permissions or response behavior, but the annotations reduce the burden.

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, then quickly covers derived parent behavior, blocking reasons, cascade_down, and the id/ids constraint. Every sentence adds useful information with 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 status-mutation tool with rich schema coverage and safety annotations, the description covers the important side effects: derived parent statuses and cascading to leaves. It does not describe return values or error behavior, but no output schema exists and the key behavioral risks are 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 100%, so the schema already documents each parameter. The description adds a useful constraint that exactly one of id or ids must be passed, and restates that blocking requires a reason and cascade_down affects all leaves. Most parameter meaning is still carried by the schema, so this is appropriately a baseline-level contribution.

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: 'Set a status on a leaf item.' It also clarifies that parent statuses are derived rather than directly set, which distinguishes this from a generic edit operation and makes the scope 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?

It gives some useful usage constraints: parent statuses are derived, blocking requires a reason, cascade_down applies to every leaf below, and exactly one of id or ids should be passed. However, it does not explicitly say when to use this tool versus siblings like tasks_edit, nor does it describe when not to use it.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description then adds real value by disclosing what the response contains and that status is 'derived' rather than stored, plus the format switch between JSON and one line per item. It omits behavior for nonexistent or malformed ids, which for a lookup tool is the notable remaining 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 dense sentence, front-loaded with the verb and resource, with the parenthetical field list and the brief flag clause both earning their place. Nothing is repeated or padded.

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

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

With no output schema, the description correctly takes on the job of naming the returned fields, and the readOnly annotation covers the mutation risk. What remains thin is the multi-id behavior (partial failures, ordering) for a tool that explicitly accepts an array of 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 coverage is 50% and both parameters are in fact documented in the schema (id format '1.2.3' and brief's one-line behavior). The description adds only the multiplicity hint ('one or more items') and restates brief's effect, so it sits at the baseline rather than compensating for anything missing.

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 ('show') and resource ('items') and enumerates the fields returned (description, assignee, dependencies, notes, derived status), so the agent knows exactly what it gets back. It does not distinguish itself from close siblings like tasks_view, tasks_list, or tasks_brief, so the agent cannot tell from the description alone which of these to pick.

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

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

There is no when-to-use guidance and no exclusions relative to the many sibling readers (tasks_overview, tasks_list, tasks_view, tasks_brief). The only usage-like statement is the brief=true rendering switch, which is about output format, not tool selection.

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

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

The readOnlyHint annotation already establishes this as a safe read operation. The description adds useful context about the returned table columns and the single-call nature, but it does not cover pagination, limits, or whether all sprint tasks are always included.

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 compact sentence that front-loads the resource and returned fields. Every phrase contributes useful information without 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?

For a simple read-only tool with one required parameter and no output schema, the description sufficiently explains the result shape by naming the key columns. It could be stronger if it clarified whether the table is paginated or exhaustive, but little is missing 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 100%, so the single 'id' parameter is already documented as 'Sprint id'. The description implies the parameter by referring to 'a sprint's tasks' but adds no syntax, format, or validation details beyond the schema.

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

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

The description identifies a specific resource and scope: a sprint's tasks, including returned fields (status, assignee, progress), and clarifies it is a single-call table view. It is clear enough to distinguish from a generic task list, though it does not explicitly name the sibling alternatives it differs from.

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

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

There is no explicit guidance on when to use this tool versus siblings such as tasks_list, tasks_overview, or tasks_show. The phrase 'in a single call' hints at efficiency, but the description does not state conditions, exclusions, or 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral detail about what is counted (status counts and open work per assignee), but it does not disclose scope, return format, or any limitations beyond that.

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, compact sentence with no wasted words. It front-loads the key information and is appropriately sized for a simple no-parameter stats 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 output schema and no parameters, the description needs to convey what the tool returns, and it does so at a high level. It could be slightly more complete by clarifying scope or output shape, but it is sufficient for an agent to understand the aggregate result.

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

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

The tool takes zero parameters, so parameter semantics are not applicable and the baseline is 4. The description does not need to compensate for schema gaps here.

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

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

The description uses a specific verb ('Counts') and names the aggregate dimensions ('per status' and 'open work per assignee'), so the tool's purpose is clear. However, it does not explicitly distinguish itself from siblings such as tasks_overview or tasks_sprint.

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 instead of alternatives like tasks_overview, tasks_list, or tasks_sprint. The intended use is implied by the stats nature of the tool, but no explicit context or exclusions 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so safety behavior is carried by structured data. The description adds that the operation targets a 'structured link' specifically, which clarifies scope, but it does not say what happens when the link does not exist (relevant given idempotentHint) or whether removal affects the linked artifact 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 front-loaded sentence with no filler or redundancy. It is efficient, though its brevity contributes to the gaps in usage and behavioral detail rather than being maximally informative.

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

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

For a low-complexity, three-required-parameter tool with full schema coverage and annotations, the definition is technically callable. It still lacks the one piece of context an agent most needs — its relationship to tasks_link and the no-op-on-missing-link behavior — 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 description coverage is 100%, including a documented id format and an enumerated set of link kinds, so the schema does the heavy lifting. The description adds no further meaning about the three required parameters, which is acceptable at baseline given the coverage.

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

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

States a specific verb and resource ("Remove a structured link from an item"), which is unambiguous on its own. However, it never names the obvious counterpart sibling tasks_link, so the agent gets no explicit differentiation between linking and unlinking beyond the verb.

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

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

There is no when-to-use statement, no prerequisite information, and no reference to the sibling tasks_link that this tool reverses. The only guidance is the implied inverse of its name, leaving the agent to infer the workflow.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds that the output is a rendered README composed of overall + current sprint + links to per-sprint files, which is useful shape information. It doesn't say whether the output is markdown text, how large it is, or whether it aggregates live data — meaningful gaps given there is no output schema.

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

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

A single front-loaded sentence with the resource first and the returned parts in a compact parenthetical; no filler and nothing redundant.

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

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

With no output schema, the description does the right thing by describing what comes back (overall + current sprint + per-sprint links). It is nearly complete for a zero-parameter read tool, but leaves the relationship to tasks_overview undefined and says nothing about the output medium or whether the per-sprint files must be fetched separately.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies no arguments are needed.

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 ('Return') and resource ('rendered task view README') and enumerates its parts (overall, current sprint, per-sprint links). It does not distinguish itself from the close sibling tasks_overview, which an agent could easily mistake for the same thing.

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

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

Usage is only implied by the content listing: an agent can infer 'call this when you want the whole view rendered at once rather than individual task records'. There is no explicit when-to-use, no exclusion, and no pointer to tasks_overview or tasks_sprint as alternatives for narrower needs.

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