Weft

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

The description adds behavioral detail beyond the annotations by specifying that calling it on a task already in the sprint is a no-op. This is useful context beyond the idempotentHint annotation, which only states idempotency without describing the exact outcome. It does not contradict any annotations.

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

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

The description is a single sentence that is front-loaded with the usage condition ('Use this when...') and includes the idempotency caveat. There is no fluff, and every word contributes to understanding the tool's purpose and behavior.

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

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

For a simple tool with two required parameters, no output schema, and no nested objects, the description covers the core purpose and a key behavioral nuance (idempotent no-op). It does not describe what happens if the task or sprint does not exist, but that may be acceptable for a straightforward operation. The description is largely complete for an agent to call the tool correctly.

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

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

The schema coverage is 0%, and the description does not mention either parameter (taskId or sprintId) at all. The parameter names are self-explanatory, but the description adds no additional meaning or clarification about their format or purpose beyond what the schema's property names imply. With zero coverage, the description should compensate but fails to do so.

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

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

The description clearly states the action: 'pull an existing task into a sprint'. It specifies the verb and resource, and implies the task is existing, distinguishing it from creation. However, it does not explicitly name alternative sibling tools like remove_task_from_sprint or move_task, so it lacks explicit sibling differentiation.

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

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

The description gives a clear context for use: 'when the user wants to pull an existing task into a sprint'. It does not mention when not to use it or provide alternatives, but the instruction is unambiguous enough for an agent to know when to invoke 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 indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context: tasks remain searchable and appear in sprint history, are never deleted, the operation has no count or undo, and idempotency is confirmed ('a second call finds nothing left to archive'). This goes beyond the annotations to fully disclose behavior, including the need for user confirmation. No contradiction with annotations.

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

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

The description is dense but well-structured. It front-loads the core purpose, then explains effects, exclusions, and idempotency. Every sentence earns its place: it covers purpose, safety, alternatives, and behavioral guarantees without redundancy. It is appropriately sized for the complexity of the operation.

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

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

For a zero-parameter, destructive tool with no output schema, the description is complete. It tells the agent when to use it, what it does, what happens to the data, how it relates to siblings, and the required confirmation step. There is no missing information that would prevent an agent from correctly invoking it.

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

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

The tool has zero parameters, and the schema coverage is 100% (no parameters to document). The description correctly avoids explaining nonexistent parameters, and the baseline for a zero-parameter tool is 4. No additional meaning is needed since there is nothing to clarify.

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

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

The description clearly states the tool's purpose: to clear the Done column by archiving all tasks in it. It uses a specific verb ('archive') and resource ('Done column'), and explicitly differentiates itself from sibling tools like complete_sprint and restore_task by explaining what it does not do (e.g., restore_task restores from trash, not archive). The purpose is unambiguous and immediately actionable.

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

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

The description provides explicit when-to-use guidance with examples ('archive everything in Done', 'clean up the board'). It also states clear exclusions: never call on your own initiative and always confirm with the user first. It references complete_sprint as an automatic alternative for finished sprint tasks, and distinguishes this tool as covering the rest. This leaves no ambiguity about when to invoke it versus alternatives.

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

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

Discloses key behavioral traits beyond the annotations: the all-or-nothing transaction, ordering ('Tasks land in each column in array order'), and append behavior ('after the column's existing tasks'), and a quota-cost rationale. These add meaningful context that the sparse annotations do not provide.

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 information-dense and well-structured: usage trigger, benefit, column semantics, sprint prerequisite, and ordering behavior follow in a logical flow. Every sentence carries necessary guidance, earning its place, and key constraints are front-loaded.

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

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

For a bulk operation with a single parameter and rich schema, the description is nearly complete: it covers when to use, how to handle sprints, and behavioral guarantees. It does not describe the response format or error behavior, but there is no output schema, and the all-or-nothing behavior is already stated.

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

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

The single top-level parameter is described in the schema ('Tasks to create, in order'), but the description goes further by explaining how to address columns (semantic or name) and how to handle sprintId when exports reference cycles/iterations. This adds operational meaning beyond the schema fields.

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: 'import many tasks at once' and 'Creates the whole batch in ONE call', distinguishing this from create_task by name ('instead of N create_task calls'). It also names sibling create_sprint for related workflow. An agent can clearly identify 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?

Explicitly opens with 'Use this when the user wants to import many tasks at once' and specifies the condition of '3+ tasks'. It names create_task as the alternative for single-task creation and gives workflow guidance for cycle/iteration fields by instructing to create sprints first via 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?

Beyond the destructiveHint annotation, the description discloses that the action cannot be undone via MCP, that finished tasks are archived and leave the Done column but remain searchable, and that unfinished tasks stay on the board. It also recommends confirmation when intent is ambiguous, adding substantial context beyond annotations.

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

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

The description is three sentences, each adding value: usage trigger, side effects, and irreversibility warning. It is front-loaded with the usage intent and avoids fluff.

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

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

For a single-parameter action with no output schema, the description covers the trigger, the behavioral outcome (archiving vs. staying), irreversibility, and a safety confirmation. Nothing essential is missing for an agent 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?

The schema has 0% description coverage and the description does not mention the 'id' parameter at all. Since the parameter is self-explanatory (the sprint identifier) and the schema provides format/required constraints, the description doesn't add meaning beyond the schema, but it also doesn't harm clarity. A baseline of 3 is appropriate given the single simple 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?

The description clearly states the tool marks a sprint complete and archives its finished tasks. It includes an example phrase ('close this sprint') and distinguishes this from completing a task or archiving tasks alone, making the purpose unambiguous.

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

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

It explicitly states when to use it: when the user has finished a sprint and wants to wrap it up. It also advises confirming ambiguous intent. However, it doesn't explicitly contrast with sibling tools like archive_done_tasks or complete_task, though the 'close this sprint' example makes the context 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals critical behavior: the call never fails for missing evidence, the server executes verification checks immediately, and the outcome placement depends on evidence and verification results. This adds substantial context that annotations do not convey.

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

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

The description is long (about 200 words) but every sentence carries necessary nuance: the key instruction is front-loaded, and later sentences explain verification and queue behavior. It is dense but not wasteful, though it could be tightened slightly.

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 tool with 11 parameters, 5 required, nested artifact objects, and a verification plan, the description covers all critical aspects: when to call, what to pass, how verification works, the distinction between Done and 'waiting on you', and the guarantee that evidence is never lost. No output schema exists, but the description compensates fully.

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 adds meaning to `outcome` (1-3 sentences summary) and `artifacts` (evidence a person can check), explaining their role and effect on task placement. It also clarifies the intent of `claims` vs `notDone` implicitly. This exceeds the baseline but does not go into every 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?

The description explicitly states when to call: 'Call this when the work on a task is actually finished.' It names the resource (task) and the action (complete), and clearly differentiates from siblings like report_progress and request_input by emphasizing that it must be called to mark a task done.

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 when-to-use and when-not-to-use guidance: 'Never report a task as done to the user without calling it.' It also explains the edge case where a task needs user input and does not move to Done but goes to their queue, and that verification failures require re-calling after fixing the work.

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 indicate non-readonly and non-destructive. The description adds valuable behavioral details beyond annotations: 'Name must be unique per board' (failure condition) and 'Color defaults to a rotating palette pick' (default behavior). This contextualizes side effects without contradicting annotations.

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

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

Three short sentences with no filler. The usage trigger is front-loaded, followed by key constraints and defaults. 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 simple creation tool with no output schema, the description covers when to use it, all parameter semantics, and key behavioral constraints. It does not explain what the response is, but that is less critical given the tool's simplicity and absent output schema.

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

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

Schema coverage is 67%, and the name parameter has no schema description. The description compensates by explaining name uniqueness, color default, and url's favicon effect, adding meaning beyond the schema's minimal descriptions for color and url.

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 ('add' / 'create') and resource ('project context') with a concrete example ('add a project for Organicus'). It clearly differentiates from sibling tools like create_task and create_sprint by focusing solely on projects.

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

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

The description explicitly says 'Use this when the user wants a new project context,' providing clear usage context. It does not explicitly name alternatives or exclusions, but the mention of 'new project' implies this is not for updating existing projects (which would be update_project).

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 `readOnlyHint: false` already signaling a mutation, the description adds genuinely useful behavioral context: the sprint is created in a 'planned' state and requires a separate `start_sprint` call to become active. This goes beyond the structured annotations and shapes agent expectations about lifecycle. It doesn't describe e.g. idempotency or duplicate policy, but that's a minor gap for this operation.

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

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

Three sentences, front-loaded with the usage trigger, and every sentence earns its place: the first gives the trigger, the second disambiguates the state and sibling, the third guards against synonym ambiguity. 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?

The core workflow (`create` → `planned` state → later `start_sprint`) is clearly described, and the parameter names are mostly self-explanatory; but there is a clear gap in parameter guidance and no mention of output or defaults, despite the schema providing no descriptions. Adequate for a simple tool, but not fully complete enough for all agent calls.

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

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

The schema description coverage is 0%, so the description must compensate for the four parameters (`name`, `goal`, `startsAt`, `endsAt`). It does not. The phrase 'plan a new sprint (e.g. 'start a sprint for next week')' only hints at date-related parameters and never explains `goal`, `name`, or the meaning or format of the time boundaries. Some parameters are inferable from their names, so this is not a bottom-score 1, but the description clearly leaves the parameter pain of the weight.

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 ('creates') and resource (`sprint`), and distinguishes itself from the sibling `start_sprint` by saying sprints are created in 'planned' state. The synonym guidance (focus, cycle, iteration, week) further disambiguates the resource. This is clear, specific, and differentiates from the most likely sibling.

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 an explicit trigger ('when the user wants to plan a new sprint'), and tells the agent when NOT to treat this as starting a sprint ('call start_sprint separately when ready to begin tracking'). This is a direct when/when-not with the relevant alternative, so an agent can route correctly without guessing.

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 indicate this is a write operation (readOnlyHint false) and non-destructive. The description adds value by revealing default column and priority behaviors, but it doesn't disclose other behavioral traits such as duplicate handling, resulting task state, or confirmation output. That's acceptable given the annotation baseline, but not exceptional.

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

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

Three tight sentences, front-loaded with trigger phrases, followed by two high-value default rules. No filler or repetition of schema content.

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

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

Given the large 12-parameter schema with complex nested objects, the description can't carry everything, but it covers the most decision-relevant defaults and usage context. Schema descriptions handle the remaining parameter meanings well enough for an agent to invoke this correctly.

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

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

The description meaningfully fills gaps left by the schema: columnId has no default in the schema, yet the description states it defaults to Backlog, and priority gets nuanced guidance ('high' for urgent/asap, 'low' for nice-to-have). Other parameters rely on their schema descriptions, making this a good complement rather than full coverage.

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

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

The description clearly states this tool captures work via trigger phrases like 'add a task' and 'remind me to …', and the title confirms the create-task action. It doesn't explicitly distinguish itself from sibling bulk_create_tasks, but the singular 'a task' vs bulk is implied.

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

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

It provides explicit when-to-use trigger phrases and useful default behaviors (Backlog placement, medium priority). It doesn't mention when to prefer alternatives like bulk_create_tasks or add_task_to_sprint, but the guidance is actionable and 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?

The annotations already declare this as a read-only, non-destructive operation. The description adds useful behavioral detail by enumerating what the fetch returns: title, full text representation, source url, and structured metadata. This is valuable because there is no output schema to convey that 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 with no filler. The first sentence states exactly when to use the tool, and the second gives the required input and expected output. It is front-loaded and every clause earns its place.

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

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

For a tool with one required parameter, read-only annotations, and no output schema, this description is complete. It tells the agent the source of the id, the id format, and the fields that will be returned, covering everything needed 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 coverage is 100% and the schema already describes the `id` parameter with its pattern and an example. The description reinforces that the id comes from `search` but does not add significant new meaning beyond what the input schema already states, so baseline 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 clearly states the tool's function: retrieve the full content of a search result using a prefixed id. It also distinguishes this from the sibling `search` tool, which presumably returns lighter results, making the purpose unambiguous.

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

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

The description explicitly tells the agent when to use this tool ('when you need the full content of a search result') and explains that the id must come from `search`. It doesn't explicitly name alternatives it should not be used for, but the context is clear and sufficient.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, establishing a safe read operation. The description adds value beyond those by disclosing that it returns null when no sprint is active and that terms like focus, cycle, iteration, or week map to the same object. This gives an agent useful behavioral expectations beyond the structured annotations.

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

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

Three sentences, each earning its place: the trigger context, the null return behavior, and the synonym mapping. The description is front-loaded with the primary usage and contains no fluff or redundant restating of the tool name.

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

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

For a zero-parameter read-only tool this is quite complete: it covers when to use it, what it returns in the no-active-sprint case, and terminology variants. One minor gap is that with no output schema, the returned sprint object's shape is not described, but the description's reference to a sprint object is likely sufficient for a simple retrieval tool.

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

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

There are zero parameters, so parameter-semantics are fully covered by the schema by definition. The baseline for zero-parameter tools is 4, and the description does not need to add anything further. No parameter documentation is 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?

The description explicitly states what the tool does: get the currently-running sprint, with concrete user-phrase triggers. It distinguishes this from sibling tools like list_sprints and list_sprints by focusing on the active sprint rather than listings. The 'currently-running' scope makes the purpose unambiguous.

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

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

Explicit usage guidance is provided: 'Use this when the user asks 'what sprint am I on?' or you need the currently-running sprint.' It also clarifies null behavior when no sprint is active, which helps an agent decide whether the result is valid to use. The synonym clarification adds practical selection guidance without naming alternatives directly.

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 and destructiveHint=false, but the description goes further by detailing exactly what the digest includes (counts, columns, projects, active sprint, Doing items, overdue, next Todo, recently closed) and warns that 'full' can exceed response limits. This adds substantial behavioral context beyond the annotations without contradicting them.

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 usage conditions, then details the digest contents, then gives alternatives and warnings. Every sentence serves a purpose, and there is no filler. It is dense but highly 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 read-only tool with one parameter and no output schema, the description fully equips an agent to decide when to call it, what to expect from each detail level, and how to route to alternatives. Nothing critical is missing.

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

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

The schema description covers 100% of the single parameter 'detail', but the tool description adds extra meaning by explaining that 'digest' is a briefing and 'full' is every field capped at 200 tasks. This goes beyond the schema's description, providing important practical context (the cap) that aids selection.

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

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

The description clearly states the tool's purpose with a specific verb ('get board state') and resource ('whole board'), and explicitly mentions the user intents it addresses ('what's on my board?'). It also differentiates from siblings by naming list_tasks and search as drill-down alternatives, making it 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?

It provides explicit when-to-use guidance tied to user queries, and when-not-to-use guidance for detail:'full' due to response limits. It names the alternative tools (list_tasks, search) and explains when they are appropriate, leaving no ambiguity.

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

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

Beyond the readOnlyHint annotation, the description adds rich behavioral detail: newest-first ordering, token budgeting, derived from recorded decisions so it cannot rot, and superseded decisions never appear. It also clarifies that lines are context, not instructions. No contradiction with annotations.

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

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

Three sentences, front-loaded with the trigger condition, and each sentence serves a distinct purpose: when to call, what it returns, and how to interpret the output. No redundancy or filler.

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

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

For a read-only tool with no output schema, the description covers return content, ordering, freshness, token budget behavior, and interpretation guidance. The agent has enough to call it correctly and understand the response. Schema and annotations cover the rest.

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 baseline is 3. The description adds a small amount of meaning by saying to scope it to a project or task, which reinforces the purpose of taskId and project, but it does not add syntax or format 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 states exactly what the tool returns: the workspace's live decisions and lessons, packed to a token budget, newest first. It distinguishes itself from siblings by noting it is derived from recorded decisions and that output is context about past choices, not instructions. The verb 'returns' and the specific resource 'context digest' are clearly identified.

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

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

It explicitly says to call this at the START of non-trivial work and advises scoping by project or task. It implies a distinction from record_decision (which creates decisions) but does not name alternatives explicitly or give a when-not-to-use condition beyond 'not instructions.' The guidance is strong but not exhaustive.

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 indicate readOnlyHint=true and destructiveHint=false, so the description need not repeat that. It adds useful behavioral context: it tells the agent how to prioritize (clear the human queue) and that the tool reveals queue status. This goes beyond annotations and helps the agent act appropriately.

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

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

The description is concise, front-loads the primary benefit, and includes actionable guidance in a natural way. It could be slightly tighter, but every sentence adds value.

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

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

Given the tool is read-only, has a simple optional parameter fully covered by schema, and no output schema or nested objects, the description is complete. It tells the agent what to expect (tasks assigned, claimed, and waiting) and how to use the result, leaving no critical gaps.

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

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

The only parameter (limit) has 100% schema coverage with a clear description, so the schema already explains it. The description does not add extra semantics for this parameter, but that is acceptable given the coverage. 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 clearly states it returns tasks assigned to the user, currently claimed work, and finished work waiting on the human. It does not explicitly name a sibling tool, but the purpose is specific and distinguishable from list_tasks and get_board_state.

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 advises using this tool instead of 'reading the whole board and guessing', implying when to use it. It also gives strategic guidance on when not to start new work (if the human queue is full). It does not mention specific sibling alternatives, but the 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 readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavior: the summary mode's token cap, the decisions mode preserving rework reasons after overwrite, and the full mode capped at 100 events with an explicit note. This goes beyond annotations and informs the agent about expected output and limitations.

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

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

The description is dense but efficient. It front-loads the purpose and use cases, then packs the three modes with concrete details in a single, well-structured sentence. Every clause earns its place without fluff.

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

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

For a read-only tool with two parameters and no output schema, the description fully covers what the agent needs: what each mode returns, the cap, and the intended usage scenarios. No critical information 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 coverage is 100%, but the description enriches the 'mode' parameter by explaining exactly what each enum value returns (summary: card+receipt+counts, decisions: all decisions with verdicts, full: raw journal). This is significant semantic value beyond the schema's simple enum listing.

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

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

The description clearly states the tool retrieves the history of a task, not its current fields, and contrasts with current-state tools. It specifies three modes with distinct outputs, making its purpose unambiguous and distinguishable from siblings like list_tasks or get_context.

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

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

The description gives explicit use cases ('before retrying failed work, judging a receipt, or answering why is this still open?') and explains which mode to pick. It does not explicitly name alternatives or state when NOT to use it, but the contexts are clear enough to guide an 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 carry idempotentHint=true and destructiveHint=false, so the description's job is to add context. It does so by specifying what idempotency means here: 'safe to call when columns already exist.' It also states the exact columns created, which goes beyond the annotation flags. No contradiction with annotations.

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

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

Two sentences, zero wasted words. The usage condition is front-loaded, followed by the idempotency guarantee. Every clause earns its place, and the structure is easy for an agent to parse quickly.

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

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

For a parameterless tool with no output schema, the description fully covers purpose, when to invoke it, and the safety of repeated calls. An agent has everything needed to decide whether to call it and what to expect. No gaps.

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

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

With zero parameters and 100% schema coverage (trivially), the description has no parameter burden. Baseline for 0 params is 4. The description doesn't need to explain parameters, and it adds relevant context about the tool's behavior instead.

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 ('initialize') and resource ('board'), and defines the scope: creates the default four columns (Backlog, Todo, Doing, Done). It distinguishes this from siblings like list_columns or get_board_state by specifying the condition 'brand-new user has no board yet', so an agent can tell exactly when this tool applies.

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 opening 'Use this when a brand-new user has no board yet' gives an explicit trigger condition. It doesn't name alternatives or say when not to use it, but the idempotent note implies it's safe even if columns exist, which covers the typical edge case. A clear usage context is present, though a brief mention of checking board state first could have been stronger.

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, destructiveHint=false, so the safety profile is clear. The description adds that results are 'in board order' and that column IDs are provided, which is useful for downstream calls. It does not describe error cases or empty-board behavior, but for a simple read operation with no parameters, this is adequate.

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

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

Two sentences, front-loaded with the usage guidance. Every word earns its place—no filler, no redundancy. The structure is ideal: usage first, then what it returns.

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 tool with no parameters and no output schema, the description covers the essential context: when to use it, what it returns, and the ordering. It could mention the exact structure of the returned columns (e.g., fields beyond IDs), but the primary use case (column IDs) is stated. Given the simplicity, it is nearly 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?

There are zero parameters, so the schema provides 100% coverage by default. Per the rubric, a baseline of 4 applies when there are no params. The description does not need to explain parameters, and it doesn't; it adds value by clarifying the return type (columns) and ordering, which is not parameter-related but is helpful.

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

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

The description clearly states the tool's function: it returns columns in board order, and it ties this to workflow stages and column IDs. This is specific (verb 'list' + resource 'columns') and easily distinguishes it from sibling list tools (list_tasks, list_sprints, etc.).

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

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

Explicit usage triggers are given: 'Use this when the user asks about workflow stages or you need column IDs for another call.' This tells an agent exactly when to invoke this tool, and implicitly when not to. No ambiguity about the 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about projects being lightweight contexts and the one-task-per-project rule, which is useful domain knowledge. However, it does not add significant behavioral detail beyond that; the includeArchived note mirrors the schema description.

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 sentences, front-loaded with the usage context, then a brief domain clarification, then the parameter tip. No fluff, every sentence serves a purpose.

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

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

For a simple list tool with one optional parameter and annotations covering safety, the description covers purpose, usage, and the parameter. It does not describe the return format, but given the absence of an output schema and the simplicity of the operation, this is not a critical 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?

The schema covers the single parameter with 100% description coverage. The tool description's mention of includeArchived repeats the schema's explanation without adding new semantic detail, so it stays at the baseline for fully documented parameters.

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

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

The description clearly states the tool's purpose: to list projects, with explicit use cases ('when the user asks about their projects' or when needing to know which projects exist before filing tasks). It distinguishes itself from sibling tools like create_project and update_project by being the listing operation.

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

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

The description provides clear context on when to use the tool, including a specific scenario (before filing tasks). It does not mention when not to use it or name alternative tools, but the guidance is explicit enough for an agent to decide correctly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond annotations: a hard result cap ('at most 100 sprints') and a synonym clarification that explains how user language maps to the resource. No contradiction or hidden behavior is apparent.

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 sentences, each earning its place: usage routing, the cap, and the synonym note. It is front-loaded with the primary purpose and immediately routes to the alternative. No waste or repetition.

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

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

For a zero-parameter, read-only, list-style tool with annotations already covering destructive/read safety, the description covers everything needed: what it lists, scope, result limit, synonym handling, and how it differs from get_active_sprint. No output schema exists, so return structure is not expected here.

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 the description must explain. The rubric baseline of 4 applies, and the description appropriately spends no space on params.

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 sprints'), explicitly covers the full scope (past, planned, active, archived), and distinguishes itself from get_active_sprint by naming the sibling. The synonym clarification (focus, sprint, cycle, iteration, week) further disambiguates the object being listed.

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 an explicit 'use this when' (general sprint queries) and an explicit alternative ('For just the running one, prefer get_active_sprint'). This is ideal routing guidance, leaving no ambiguity about when to select this tool over a sibling.

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

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

Annotations already cover readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds important behavioral details beyond that: the 200-task cap, the suggestion to filter if truncated, and the inclusion of archived tasks for sprint-scoped queries. These are not in the annotations and give the agent critical expectations about output volume and scope.

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

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

Two sentences with no filler. The purpose is front-loaded, the cap and archived behavior are stated in the second sentence, and the alternative tool is mentioned last. 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 list tool with five optional parameters and no output schema, the description covers the core behaviors: return scope, cap, archived inclusion, and the alternative. It doesn't mention pagination or sorting, but those are likely not essential given the tool's simplicity and the annotation coverage. The description gives enough for an agent 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 each parameter is already documented. The description adds a practical hint that columnId and sprintId should be used to avoid truncation, but doesn't redefine the parameters themselves. This meets the baseline for well-covered schemas.

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

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

The description opens with a specific use case ('tasks scoped to a specific column or sprint') and then clarifies the unfiltered behavior ('returns every task on the board'). It explicitly names the sibling tool it is not ('Prefer get_board_state'), making the purpose 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?

Gives explicit when-to-use ('when the user wants tasks scoped to a specific column or sprint') and when-not-to ('Prefer get_board_state when the user wants a general overview'). Also warns about truncation and tells the agent to filter by columnId/sprintId, guiding parameter selection.

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

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

The description goes beyond annotations by disclosing side effects: moving to semantic='doing' starts cycle-time tracking, moving to semantic='done' records completion time, and the operation is idempotent. This adds meaningful behavioral context that annotations alone do not provide.

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 sentences with zero waste: the trigger condition, the alternative guidance, and the side-effect warning are each distinct and front-loaded. 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 tool with 3 required params, no output schema, and annotations that already cover idempotency, the description covers the main usage scenario, the prerequisite (list_columns), the side effects, and alternatives. It does not describe the return value or failure modes, but given the simple signature, this is nearly complete.

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

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

Schema coverage is 0%, so the description carries the burden of explaining parameters. While it doesn't document individual parameter formats, it gives essential operational context (requires columnId from list_columns, must specify position and target column). The id, toColumnId, and position semantics are partially inferred rather than fully explained, but the description provides the key conceptual meaning.

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

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

Description states the exact verb+resource ('move a task to a specific column or change its order within a column') and distinguishes it from start_task/complete_task. The distinction from siblings is explicit, naming the preferred alternatives for the user's own workflow.

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 when to use this tool (move to specific column/change order), states it needs a columnId from list_columns, and names alternatives (start_task/complete_task) that require no column ID. This gives clear 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?

Annotations only say the tool writes but is not destructive. The description adds crucial behavioral context: records are immutable, changes require a new record with supersedesId, verdict relay clears the task from the review queue, and the agent is 'the messenger, not the decider'. This goes well beyond the structured hints.

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

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

The description is long but tightly structured with numbered modes, bolded labels, and scannable examples. Every sentence adds operational value for a complex 14-parameter tool; there is 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?

The description is nearly complete for a dual-mode write tool, covering triggers, side effects, immutability, and downstream consumers like get_context. However, the schema marks options as the only required parameter, yet the description's verdict-relay path never instructs the agent how to satisfy that requirement, so a faithfully-following agent could build a call that fails validation.

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%, but the description adds a conceptual layer the schema lacks: it groups id/decision/note as the verdict-relay path and title/outcome/MADR fields as the standalone-record path. It also sharpens semantics for supersedesId and warns that options weighed must not be a retrofit.

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

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

Opens with 'Two uses, one table of record' and clearly enumerates both: relaying a verdict from conversation and recording a standalone decision worth remembering. This gives a specific verb and resource for each mode and distinguishes the tool from siblings like create_task and update_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?

Provides explicit triggers ('whenever the user makes a real choice in conversation') and explicit exclusions ('Never call this to accept your own work', 'the user did not object is not a decision'). It also clarifies when each of the two modes applies, leaving no ambiguity about selection.

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

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

The description adds behavioral context beyond the annotations: it states the operation is idempotent (matching the idempotentHint annotation) and clarifies that the task remains on the board, which is a non-obvious side effect. It does not contradict annotations. It could mention whether the task's sprint field is set to null or moved to a backlog, 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?

The description is three short sentences, each earning its place: the usage trigger, the key non-destructive behavior, and the idempotency guarantee. It is front-loaded with the action and avoids any fluff.

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

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

For a single-parameter, non-destructive, idempotent operation, the description is nearly complete. It covers the action, the non-deletion guarantee, and the board persistence. It does not describe the return value, but there is no output schema, and for a simple mutation tool this is a minor gap. The sibling list provides enough context for an agent to distinguish this from related tools.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter 'taskId'. The description does not explicitly explain that 'taskId' is the identifier of the task to detach, but the tool name and description make it obvious. The schema already provides the UUID format and pattern, so the description adds little beyond what is inferable. Baseline 3 is appropriate because the parameter is self-evident from context.

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

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

The description clearly states the action ('detach a task from its current sprint'), the resource (task), and the key distinction from deletion ('without deleting it', 'remains on the board'). It also explicitly names the sibling tool 'add_task_to_sprint' in the context, making the purpose unambiguous.

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

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

The description provides clear context for when to use the tool ('when the user wants to detach a task from its current sprint') and explicitly states what it does not do ('without deleting it'). It does not explicitly name alternative tools or exclusions, but the sibling list includes 'add_task_to_sprint' which is the obvious inverse, and the description's clarity makes the usage context strong.

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

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

Goes well beyond annotations (idempotentHint=true, readOnlyHint=false) by disclosing the renewal semantics, the deliberate abandonment design, and the rationale that silence is the only signal the board has. It also explains that blocked/needs_input statuses 'park the task for the human,' which is behavioral context the annotations cannot express. No contradiction with annotations.

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

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

Four sentences, roughly 100 words, with the core instruction front-loaded ('Say you are still working') before the mechanics and rationale. Every sentence earns its place — even the dead-agent rationale is justified behavioral transparency rather than fluff. No redundancy with the schema.

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

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

For a 5-parameter tool with no output schema, the description covers the operational essentials: cadence, failure mode, and the two use cases. The only notable gap is that it does not hint at what the call returns (e.g., renewed expiry time), which matters given no output schema exists. The learnings parameter's nuanced rules are fully handled by the schema, so their absence from the description is acceptable.

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 schema already documents all five parameters, including the status enum semantics and the rich learnings guidance. The description adds the cadence context linking runId/leaseToken to the renew cycle, but that is marginal on top of the schema already saying 'returned by start_task.' Baseline 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 clear, specific purpose in the first sentence — 'Say you are still working' — and unpacks it as a claim-renewal heartbeat tied to renewEverySeconds from start_task. It distinguishes itself from siblings by explaining that without this call the task is 'treated as abandoned and offered to someone else,' which no other sibling covers. The secondary purpose ('the place to say you are blocked or waiting on the user') is also explicit.

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 explicit when-to-use guidance: 'call this at least every renewEverySeconds returned by start_task, and it renews,' plus the consequence of silence (abandonment). It also names the secondary trigger ('blocked or waiting on the user'). It stops short of a 5 because it never explicitly names sibling alternatives or says when NOT to use it (e.g., use complete_task when done), leaving that to inference.

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?

Adds substantial context far beyond the annotations: the call returns immediately, the claim is kept when there is no user, repeated identical calls become waits of ~20 seconds, fresh credentials arrive, polling on one's own initiative is forbidden, and each question spends user attention. This materially changes invocation behavior and is precisely the kind of trait an agent needs.

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

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

The description is dense but every sentence carries behavioral or usage weight; nothing is filler. It is front-loaded with the core purpose and the irreversible-use boundary. Slightly more structure (bullets for the different waiting modes would improve scannability, but this is a complex tool and the length is justified.

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 tool with no output schema and several asynchronous behaviors, the description covers all essential call paths: immediate return, submit_answer handoff, no-user case, repeated-call wait, form channel, and attention-limit warning. An agent has what it needs to invoke it correctly in each 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 coverage is 100%, so the baseline is 3, but the description goes further by explaining the intended semantics of options ('alternatives get read, yes/no gets rubber-stamped'), channel:'form' behavior, holdSeconds timing (20s repeated, form default 120s), and the meaning of reusing the same arguments.

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: 'Register a question only the user can answer, and keep your place on the task while it is open.' It clearly distinguishes from sibling submit_answer, which is named as the follow-up call that delivers the answer.

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 explicit boundaries for when to use it ('ONLY for what is irreversible... or a real fork with no reasonable default'), a hard 'never' ('may I continue?'), and a preference rule for options. It also routes to the channel:'form' alternative and submit_answer sibling.

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 indicate it is not read-only (write operation) and not destructive (restore is constructive). The description adds the 30-day recovery window and directs the agent to use the id from trash_task, but it does not disclose behavior around errors, idempotency, or what happens if the task is already restored. Since annotations cover the basic safety profile, the description adds some context but not rich behavioral detail.

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

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

The description is two sentences with no filler. The use case is front-loaded, followed by the parameter guidance. Every word earns its place, making it efficient and easy to parse.

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

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

For a single-parameter tool with no output schema and annotations present, the description covers the trigger condition and the parameter source. It omits details like success/error responses, but given the simplicity and lack of output schema, it is sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must explain the parameter. It does: the id is 'the id returned by trash_task', which gives the agent clear provenance and intent beyond the schema's bare 'uuid' format. This is essential for correct invocation.

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

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

The description clearly states the tool restores a deleted task, with a specific use case ('undo that delete', 'restore the task I just removed') and a 30-day window. It implicitly differentiates from siblings like trash_task by naming it as the source of the id, making the purpose 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?

It explicitly says when to use this tool ('when the user wants to recover a task they deleted in the last 30 days') and gives a concrete example. However, it does not state when not to use it or name an alternative tool (e.g., if the task is not in the trash or if you need to recover a permanently deleted task), so it lacks explicit 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 readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral detail: case-insensitive substring matching, the list of searched fields, the ranked result shape with kind-prefixed ids, and the 50-match limit. This gives the agent a clear model of behavior beyond safety annotations.

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

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

The description is dense but every sentence earns its place: triggering intent, search scope and matching behavior, result format, and limit warning. It is well-structured and front-loaded with the usage guidance first.

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

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

Given a single parameter, read-only annotations, and no output schema, the description fully covers what an agent needs: when to call, what is searched, what the response contains, and how to handle truncation. No significant gaps remain.

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

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

The schema already describes query as a required free-text, case-insensitive string, so schema coverage is 100%. The description adds meaning by explaining what the query is matched against, that matches are ranked, and that results are truncated at 50, which enriches the single parameter's semantics beyond the schema.

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

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

The description states a specific verb and resource: keyword search across tasks, sprints, decisions, and memory notes, with concrete examples. It clearly distinguishes search from sibling tools like list_tasks or get_context by focusing on arbitrary keyword lookup rather than structured listing.

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

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

It explicitly says 'Use this when the user wants to find anything the board remembers by keyword' and provides example user intents. It does not explicitly name when not to use it or contrast with alternative siblings, so it falls just short of full routing 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?

The description discloses a key behavioral constraint not fully captured by annotations: only one sprint can be active, and the tool fails and names the active sprint if one is already running. It does not spell out the state change ('active sprint' becomes this one), but the failure mode is enough to prepare an agent. No contradiction with readOnlyHint=false, destructiveHint=false, or openWorldHint=false.

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 and every sentence earns its place: the first states the triggering condition, the second states the constraint and recovery path. The most important usage condition is front-loaded, and there is no filler or repetition.

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

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

For a single-parameter mutation tool with no output schema, the description provides the essential use case, the active-sprint constraint, and the retry path. It could be stronger by explicitly identifying the id parameter as the target sprint and pointing to list_sprints or get_active_sprint, but these are minor gaps, not critical omissions.

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

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

The only parameter, id, has no schema description and the description does not explicitly define what id refers to. It is contextually implied that id is the sprint to start, but the description never directly says this. With 0% schema coverage, the description should compensate, and it does not.

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

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

The description opens with a specific action ('begin a previously planned sprint') and clearly distinguishes this from related siblings like create_sprint and complete_sprint. The one-active-sprint rule and the explicit mention of complete_sprint further remove ambiguity about what this tool does and does not do.

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

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

It states exactly when to use the tool: when the user is ready to start a previously planned sprint. It also gives a concrete exclusion and recovery path: if another sprint is active, complete it via complete_sprint, then retry. This is explicit, actionable guidance with no need for inference.

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, readOnlyHint=false, destructiveHint=false. The description adds valuable behavioral context: the lease mechanism, the need to keep runId and leaseToken, the renewal requirement, and the meaning of the two refusal responses. It doesn't contradict annotations. It doesn't detail what happens if the lease expires beyond the claim being offered to someone else, but that is already stated. A 4 is appropriate because it adds meaningful behavioral context beyond the annotations.

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

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

The description is a single dense paragraph that front-loads the most important instruction ('Call this the moment you begin executing a task — BEFORE doing the actual work'). It covers the lease, renewal, refusals, and next step without wasted words. Slightly long but 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 single-parameter tool with no output schema, the description is quite complete: it explains the lease, the return values (runId and leaseToken), the renewal cadence, the two expected refusals, and the follow-up call. It doesn't describe the exact response format, but no output schema exists and the key return values are named. A 4 is fair.

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 only parameter (id) is described as 'Task ID' in the schema. The description doesn't add much beyond that, but with a single required UUID parameter, the schema is sufficient. Baseline 3 is correct.

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

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

The description states a specific verb ('Call this the moment you begin executing a task'), a specific resource (the task being claimed), and a clear action (claims the task with a lease, moves it to Doing, starts cycle-time tracking). It clearly distinguishes itself from siblings like complete_task and report_progress by naming them and describing the workflow.

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

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

The description explicitly says when to call it ('the moment you begin executing a task — BEFORE doing the actual work'), what to do after (call report_progress at least every renewEverySeconds), and what to do when finished (call complete_task). It also explains two expected refusal responses and how to handle them, which is strong usage 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?

The description goes well beyond the annotations, explaining that the tool returns runId and leaseToken for resuming the same attempt, that an answer from another channel is returned instead of an error, and that invented answers are treated as worse than no answer. It directly addresses idempotency-related behavior without contradicting the idempotentHint=true annotation.

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

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

The description is front-loaded with the core purpose and each sentence earns its place by adding behavioral or usage constraints. It is slightly verbose in the warning about invented answers, but the dramatic framing reinforces a critical safety rule without becoming irrelevant.

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

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

Despite having no output schema, the description tells the agent what to expect in return (runId and leaseToken) and how to handle edge cases like declined answers, absent users, and answers arriving from another channel. This is complete enough for an agent to invoke the tool correctly without guessing.

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 three parameters (value, answer, questionId) are already documented in the schema. The description reinforces that the answer must be 'their words' but adds no parameter-specific meaning beyond what the schema provides. Baseline 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 opens with a specific verb and resource: 'Bring back what the user said to a question you raised with request_input, and pick the work up again.' It clearly distinguishes this from its companion sibling request_input by framing it as the follow-up step. The purpose is 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 description gives explicit when-to-call guidance: 'Call it the moment they answer, with their words.' It also gives explicit when-not-to-call guidance: 'If they declined to answer, or nobody was there, do not call this: leave the question in their queue.' This leaves no ambiguity about selecting it over 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?

Beyond the destructiveHint annotation, the description adds material behavior: the task is recoverable for 30 days via restore_task, after which a scheduled job physically deletes it, and it warns not to guess among ambiguous matches. This is substantial extra context and is consistent with annotations.

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

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

Three short sentences, front-loaded with the primary use, followed by the key consequence and an important disambiguation caveat. Every sentence adds necessary 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 simple one-parameter destructive action, it covers use trigger, retention/restoration path, and ambiguity handling. It does not discuss what happens on invalid IDs or the return value, but no output schema exists and these are minor for this tool.

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

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

Schema description coverage is 0%, and the description never directly explains that id must identify the task to trash. However, the single id parameter is largely self-explanatory from context and the schema provides a UUID format and pattern, keeping the gap 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?

Description opens with 'Use this when the user asks to remove or delete a task' and clearly states it moves a task to the trash, a soft-delete distinct from permanent deletion and from completing a task. The mention of restore_task helps separate it from related workflow tools.

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

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

It gives an explicit trigger ('remove or delete a task') and instructs to ask the user to pick one when multiple tasks match. It does not explicitly contrast with complete_task or remove_task_from_sprint, so it stops short of full when-not/alternative 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?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description discloses partial-update semantics ('Only fields you pass are changed') and the archive behavior ('archived: true hides it from pickers; its tasks keep the association'). This adds meaningful behavioral context without contradicting the annotations.

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

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

Three concise sentences: the first states all primary actions, the second clarifies partial updates, the third declares idempotency. No filler, and the most important info is front-loaded.

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

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

For a simple update tool with 5 flat parameters and no output schema, the description covers the essential behaviors: what fields can be changed, how archiving affects visibility, and that the operation is idempotent. It doesn't mention return values or errors, but those aren't required given the tool's simplicity and available 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 0%, so the description must compensate. It effectively maps every parameter: 'rename' for name, 'change its color' for color, 'website url' for url, 'archive/unarchive' for archived, and id is implied as the project identifier. It also adds crucial detail on the archived field's effect, which the schema cannot convey.

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 specific verbs and resources: 'rename a project, change its color or website url, or archive/unarchive it'. This clearly scopes the operation to project-level updates and distinguishes it from siblings like update_task (task-level) and create_project (creation).

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 opens with 'Use this to', giving explicit instruction on when to invoke it, and enumerates the exact use cases. It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough given the sibling list and the operation's specific scope.

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

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

Beyond the annotations (idempotentHint=true, destructiveHint=false), the description reveals partial-update semantics ('Only fields you pass are changed; omitted fields stay as-is'), the one-way nature of requiresReview, and the atomic all-or-nothing refusal when sending false against a standing flag. These are non-obvious behavioral traits that materially affect how the tool should be called.

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

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

The purpose is front-loaded in the first sentence and the requiresReview exception is a necessary warning, but the one-word 'Idempotent.' sentence duplicates the idempotentHint annotation, and the final sentence is dense. Overall it is compact and well-ordered, earning a 4 rather than a 5.

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

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

Given the 11 parameter schema carries detailed descriptions for project, assignee, blockedBy, verification, and requiresReview, the tool-level description can stay short and still be sufficient. It explains the patch model and the one dangerous flag, and directs the agent to complete_task for releasing flagged work. The absence of any return-value note is a small gap, but no output schema exists and the description covers the non-obvious call semantics.

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

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

The description connects user intents to parameters (rename→title, re-prioritize→priority, re-estimate→estimateMinutes) and adds the crucial patch semantics that omitted fields are untouched. With only 36% schema description coverage, this helps, but it doesn't individually explain the many undocumented fields such as dueAt, description, or estimateMinutes, leaving the schema types to carry that weight.

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

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

The description opens with 'Use this when the user wants to rename, re-prioritize, re-estimate, or otherwise edit an existing task,' giving a specific verb, resource, and example fields. It clearly separates update from create_task via 'existing task,' but it does not explicitly rule out overlapping siblings like move_task or complete_task, so differentiation is implicit rather than named.

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

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

'Use this when...' is an explicit trigger condition, and the requiresReview paragraph states the one case where update_task must not be used to clear the flag, naming complete_task as the alternative. This provides clear when-to-use and when-not-to-use guidance for the trickiest scenario, though it doesn't enumerate alternatives for every sibling.

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