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

Discloses all-or-nothing validation and per-task activity logging. No annotations exist, so description carries full burden. Could mention authorization or idempotency.

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, no fluff. Front-loaded with purpose and use cases.

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?

Covers purpose, behavior, and key constraint. No output schema, so missing return details. Missing permission or error handling info, but acceptable for bulk 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 covers all parameters with descriptions. Description adds overall semantics (same update applied to all) but does not deepen individual parameter meaning beyond 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?

Clearly states 'Apply the same update to multiple tasks' and gives specific use cases (consolidation, bulk status/priority/agent changes). Distinct from single-task update tool.

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?

Describes when to use (consolidation, bulk changes) but lacks explicit when-not-to-use or alternatives. Context from siblings makes it clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses defaults ('status='active', priority='medium' unless overridden'), the return structure, and the shallow merge behavior for metadata. It does not discuss auth or idempotency, but the description is sufficient for a creation tool.

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

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

The description is five sentences, front-loaded with purpose, followed by usage guidelines, then defaults and return value. Every sentence adds value, with no redundancy or empty words. It is appropriately sized for the tool's complexity.

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 lack of output schema and annotations, the description covers all essential aspects: creation purpose, defaults, return format, and usage guidelines. It also clarifies a nuanced parameter (priority). This completeness allows an AI agent to use the tool correctly without additional 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 baseline is 3. The description adds significant value: it explains the priority field's distinction from task.priority, suggests usage levels, and provides examples for metadata. Each parameter gets extra context beyond the schema, making this highly informative.

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 verb ('Create'), resource ('project'), and purpose ('to group tasks and sessions under a shared goal'). It distinguishes from sibling tools like board_create_task and board_create_session by emphasizing that projects are the top-level container. This meets the highest standard of purpose clarity.

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: 'Use sparingly: create a new project for major initiatives (3+ related tasks), not for every piece of work.' It implies that for small pieces of work, existing projects or task creation should be used. While it does not name alternatives explicitly, the sibling tool names provide enough context for an AI 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?

Description clearly discloses the side effect: any currently-active sessions on the same project are automatically marked 'abandoned'. Also explains return structure in detail (handoff contents, activity log). Since no annotations are provided, the description fully covers behavioral transparency.

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

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

Front-loaded with main purpose and side effect. Every sentence adds unique information (side effect, return fields, usage instruction). No fluff. Efficiently structured for an agent 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?

Given no output schema, description explains the return object fields in detail (handoff sections, active_tasks, recent_activity). Fully covers what the agent needs to understand the tool's outcome and side effects.

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

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

Schema coverage is 100% so baseline is 3. Description adds meaning: for 'session_type', it explains the three types ('solo', 'team', 'background') with brief context; for 'metadata', provides example and states it is stored verbatim. Adds value beyond 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?

Clearly states the tool starts a new work session and retrieves the previous handoff. Verbs are specific ('start', 'get') and resource identified ('session on a project'). Distinguishes from sibling tools like 'board_end_session' and 'board_get_handoff'.

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 instructs to call at the start of every substantive session so the next one can pick up. Implies when to use but does not explicitly state when not to use or list alternatives. The side effect about aborting other sessions is clear 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?

Discloses side effects: audits activity_log entry, auto-sets started_at/completed_at based on status, and notes depends_on is advisory. No annotations exist, so description fully covers behavioral traits.

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?

Six sentences, front-loaded with core purpose, every sentence adds value with no redundancy.

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

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

Covers key aspects: defaults, side effects, subtask pattern, dependency advisory, and return fields. Missing error handling or idempotency, but sufficient for a creation tool of this complexity.

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

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

Schema coverage is 100%, but description adds value by explaining auto-set behavior for status transitions and contextual use of parent_task_id and depends_on beyond schema descriptions.

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

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

The description clearly states it creates a task in a project and details defaults and side effects. It distinguishes from siblings by explicitly covering creation-specific features like subtasks and dependencies.

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 guidance on defaults, subtask creation (parent_task_id), and dependency usage (depends_on), and notes it's for decomposing work. Lacks explicit when-not-to-use or alternatives, but creation 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?

No annotations provided, so the description fully shoulders behavioral disclosure. It reveals irreversibility, hard-delete nature, cascading subtasks, deletion of activity_log entries, and the require_done safety guard. This is comprehensive.

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 conveying all essential information without fluff. Front-loaded with the core action, then safety and side effects. Highly efficient.

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

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

Despite no output schema, the description covers required parameters, side effects (activity_log), irreversibility, and safety guard. Sufficient for an agent to use 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?

Input schema has 100% coverage with descriptions for all 3 parameters. The description adds some extra nuance (e.g., 'Pass require_done=false to override'), but does not significantly exceed the schema. 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?

Clearly states it hard-deletes a task and optionally its subtasks. The verb 'delete' and resource 'task' are specific, and it distinguishes from siblings like board_update_task or board_create_task which are not delete operations.

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 context on when to use (deleting done tasks) and safety guard to prevent deleting in-progress work. However, it does not explicitly compare with sibling tools or suggest alternatives for other operations.

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

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

With no annotations provided, the description fully explains behavioral traits: marks session as 'completed', sets ended_at=now, and how the next session surfaces this session's data. It also specifies the return format. It could mention if the session can be reactivated or if ending is irreversible, but is sufficiently 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 5 sentences, each adding value. It is front-loaded with the most important point. Could be slightly more concise, but no extraneous information. Good structure.

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 no output schema, the description explains the return shape. It integrates well with sibling tools (board_create_session). It documents required parameters and complex nested objects. Lacks error conditions or edge cases (e.g., ending already ended session), but is largely complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema: for handoff_notes it advises referencing task IDs and notes that the next session reads it as prose; for context_artifacts it explains recognized keys and that additional keys are passthrough. This helps the agent use parameters correctly.

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 ends the current session with a progress summary and handoff notes, and emphasizes its critical role in cross-session continuity. It distinguishes itself from siblings like board_create_session (which starts a session) and board_get_handoff (which retrieves handoff data).

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 this call is essential for cross-session continuity and that without it, session work is invisible to the next one. It provides guidance on when to use it (at session end) and what to include (reference task IDs in handoff_notes). It does not explicitly state when not to use alternatives, but the context makes it clear.

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

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

No annotations exist, so the description carries the burden. It discloses ordering (newest-first) and capping (default 50, max 200). It implies a read operation via 'Query', but could explicitly state it is read-only. Overall 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 action, no wasted words. Each sentence adds value: what it does, filters, ordering, limit, use cases.

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

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

The description covers filters, ordering, and limit. However, without an output schema, it lacks return structure details. For a query tool with 5 optional parameters, it is mostly complete but could mention return fields.

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

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

Schema coverage is 100%, so baseline is 3. The description groups the filters but adds little beyond schema descriptions, except for the limit default and max. The schema already specifies enum values for action.

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

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

The description uses a specific verb 'Query' and resource 'activity_log', and lists filter criteria and output characteristics. It clearly distinguishes itself from siblings like 'board_log_activity' and 'board_get_handoff'.

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 use cases: auditing, reconstructing sessions, following actions. It mentions ordering and capping but does not explicitly state when not to use it or alternatives. However, the use cases are clear.

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

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

No annotations provided, but description comprehensively lists returned fields. Does not disclose side effects or limitations, but for a read operation this is sufficient.

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?

Description is informative and well-structured, front-loading purpose and usage. Slightly lengthy 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?

Covers purpose, usage, and return shape thoroughly. No output schema but description details fields. Lacks error or rate limit info, but acceptable for a read tool.

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

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

Only one parameter with schema coverage 100%. Schema already describes it well; description adds no extra meaning beyond indicating it reads handoff 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 tool reads handoff context for a project without starting a new session. It distinguishes from board_create_session, providing a specific verb and resource.

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: mid-session to re-check pending items or for background agents without claiming a session slot. Contrasts with board_create_session for session start.

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

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

With no annotations, the description fully discloses sorting order, default priority handling, and the exact output fields including task_counts. This provides comprehensive behavioral context for a read-only list tool.

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

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

The description is front-loaded with the main action and context, every sentence adds value, and there is no redundant or extraneous information. It efficiently conveys all necessary details.

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

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

Given the tool's low complexity (one optional parameter) and no output schema, the description adequately explains the output structure, sorting, and usage context, making it complete for an AI agent to select and invoke 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 input schema covers 100% of parameters with a detailed description for the 'status' parameter, including usage notes. The tool description does not add additional parameter semantics beyond what the schema provides, 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 purpose: 'List all projects with per-status task counts.' It also explains the context of use (session start) and distinguishes from sibling board_get_tasks.

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

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

Explicitly guides the agent to call this at session start before creating tasks, and notes that returned IDs are required for other tools. Directly recommends using this over board_get_tasks when target project is unknown.

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?

Without annotations, description fully discloses behavior: returns every field (listed), returns { error } on missing task instead of throwing, and advises callers to check for error key.

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?

Front-loaded with purpose, uses clear structure. The field listing is necessary due to no output schema, and the description is efficient without waste.

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

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

For a simple single-fetch tool with one parameter and no output schema, the description covers return format, error handling, and use case completely.

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?

Description largely echoes the schema's parameter description ('Task ID to fetch...'). While it adds context on usage, it does not provide significantly new semantics beyond the schema, so baseline 3.

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

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

Description clearly states 'Fetch a single task by its ID', specifies verb and resource, and distinguishes from sibling board_get_tasks which lists many tasks.

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

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

Explicitly tells when to use (when you have a task ID and need full record) and when not to (for listing many, use board_get_tasks). Also provides sources for obtaining the ID.

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

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

Discloses sorting by priority (client-side), default exclusion of done tasks, and the condition when include_done is ignored. Lists all returned fields including ISO timestamps. No annotations provided, so description carries full burden and meets it well.

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

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

One paragraph, front-loaded with purpose and key behavioral note, then usage advice, alternative, and return format. No wasted words.

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?

Without output schema, description compensates by enumerating return fields. Covers behavior, filtering options, sorting, alternatives. Very comprehensive.

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

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

Schema already provides descriptions for all 5 parameters (100% coverage). Description adds context like 'keep responses tight' and explains the logic of default done exclusion, but does not add new parameter-specific details beyond schema descriptions. However, the additional context is helpful for parameter usage.

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 clearly states it lists tasks in a project with optional filters and distinguishes from board_get_task by pointing out the single-task counterpart. Specific verb 'list' and resource 'tasks'.

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

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

Explicit usage advice: use for mid-session checks, almost always pass a status filter to keep responses tight. Also points to board_get_task as an alternative for single task retrieval.

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

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

No annotations provided, so the description carries the burden. It declares write-only behavior, return structure ({ id, action, message }), and that action is an enum. Does not discuss idempotency or side effects, but adequately conveys core behavior.

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

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

Two paragraphs are concise and well-organized. The first sentence front-loads the purpose. Every sentence adds value, avoiding 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?

Given no annotations and no output schema, the description thoroughly covers purpose, usage, parameter semantics, return value, and ties to sibling tools. Leaves no significant gaps for an agent to misunderstand.

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 description adds significant context beyond the schema: explains use of 'commented' action, details requirement for 'commented', purpose of task_id/session_id for filtering, and that metadata is stored verbatim and unindexed.

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: appending entries to an activity_log as a write-only audit stream. It distinguishes itself from sibling tools that auto-log lifecycle events, emphasizing use for free-form comments and arbitrary actions.

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 describes when to use (research observations, decisions, blockers, failures) and when not to (status/assignment changes are auto-logged). Provides alternatives like board_get_activity for reading and notes that board_update_task/board_create_task auto-log.

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

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

With no annotations, the description carries the full burden. It discloses behavioral traits like valid status transitions (active→paused, etc.) and the effect of passing null to description/metadata (clearing them). It also implies that archiving removes clutter from the active list. However, it doesn't mention permissions, reversibility of actions, or whether updates trigger side effects.

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

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

The description is three sentences, front-loaded with the main action. The first sentence states what it does, the second gives usage scenarios, and the third clarifies null handling. No extraneous information, 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?

Given the 6 parameters (1 required) and no output schema, the description covers the key functionality and clarifies important behaviors like status transitions and null semantics. However, it doesn't mention that project_id is required (though the schema lists it) or describe the response after a successful update. Still, it provides enough context for the agent to use the tool effectively.

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

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

Schema coverage is 100% with detailed descriptions for each parameter. The tool description adds minimal extra nuance beyond summarizing the purpose. It reiterates the null behavior for description and metadata, but the schema already covers that. Therefore, the description does not significantly enhance parameter understanding 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 clearly states it updates a project's status, priority, name, description, or metadata. It distinguishes from sibling tools by focusing on project-specific fields and providing concrete examples like pausing, archiving, and reranking priority.

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 usage scenarios: pausing projects on hold, archiving completed ones, and reranking priority during weekly reviews. While it doesn't explicitly list when not to use or directly compare with siblings, the context is clear and actionable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that moving a task to a different project requires the target project to exist and that subtasks are not automatically moved, which is a critical behavioral detail. However, it doesn't mention other side effects like idempotency or auth requirements.

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

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

The description is extremely concise, consisting of two sentences that front-load the main purpose and immediately follow with the key behavioral caveat. Every sentence adds value with no redundancy.

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

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

Given the complexity (10 parameters including nested objects) and no output schema, the description covers the primary purpose and a critical behavioral detail. However, it does not explain the return value or error conditions, which would be helpful but are not required since no output schema exists.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the project_id parameter's behavior (subtask handling warning). Other parameters are self-explanatory from the schema descriptions, so no significant additional meaning is needed.

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

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

The description explicitly states it updates a task's status, assignment, priority, RIPER mode, project, or other fields, distinguishing it from sibling tools like board_create_task or board_delete_task. It uses specific verbs and resources.

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

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

The description clearly indicates when to use the tool (to update various task fields) and includes a specific warning about moving tasks between projects and the need to handle subtasks separately. While it does not explicitly list alternatives, it provides sufficient context for usage decisions.

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