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

No annotations are provided, so the description carries the full behavioral burden. It states the mutation ('Add') and markdown format, but omits auth requirements, rate limits, whether comments appear as the authenticated user, and what happens on success or failure. The disclosure is very thin.

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

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

The single sentence is front-loaded, waste-free, and appropriately sized for a simple two-parameter tool.

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

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

For a simple mutation with complete parameter schema, the description provides enough to call the tool correctly. The only minor gap is the absence of return-value information, since no output schema exists, but an agent can still invoke it reliably.

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 repeats the markdown format but adds no syntax, constraints, or examples beyond what the schema already documents for taskId and markdown.

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') and resource ('comment to a task'), distinguishing it from sibling tools such as weeek_list_comments and other task operations. An agent can identify the tool's function immediately without opening the schema.

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

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

The purpose implies when to use the tool (to add a comment to a task), but there is no explicit when-to-use guidance, no prerequisites, and no alternatives named. With only one comment-adding sibling, the implied usage is minimally adequate.

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

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

With no annotations, the description carries the full behavioral burden. It implies a mutation but says nothing about reversibility, required permissions, whether other fields change, or side effects such as notifications — all relevant for a completion action.

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

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

A single efficient sentence with no wasted words, front-loading the action and key. It is appropriately sized for a one-parameter tool, though very terse.

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-parameter mutation with no output schema, the description is minimally adequate, but it omits error/edge-case behavior (e.g., what happens if the task is already complete) and any side-effect context that annotations would normally supply.

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 single taskId parameter is fully documented in the schema. The description's 'by its id' simply echoes the schema, so no additional semantic value is added; baseline 3 applies.

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

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

States a specific verb (mark completed) and resource (task) with the scoping key ('by its id'). However, it offers no differentiation from the sibling weeek_update_task, which plausibly also sets task status, so an agent can't tell them apart from the description alone.

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

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

There is no statement of when to use this tool versus alternatives like weeek_update_task, nor any prerequisites or context. The agent must infer usage entirely from the name.

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

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

With no annotations provided, the description carries the full disclosure burden, and it discloses almost nothing: no statement about required permissions, whether the board is created empty (no columns/tags), what is returned, or whether the operation is idempotent. 'Create' at least signals a write operation, but that is the sole behavioral signal.

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

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

A single short sentence with the action and target front-loaded and no filler. It is efficient, though its brevity reflects under-specification rather than disciplined editing.

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

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

For a mutation tool with no annotations and no output schema, the description should cover permissions, side effects, and what the caller gets back; it covers none of these. Only the two fully-documented parameters are adequately specified.

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 both parameters (name, projectId) are documented in the schema itself, so the description adds no syntax or format detail beyond it. This is the baseline case where the structured schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Create a board') and scopes it to a project, which is enough to distinguish it from the list-oriented siblings. It stops short of explicitly naming alternatives, but the action is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g. must the project already exist?), and no mention of related operations such as listing boards afterwards. Usage is only implied by the verb.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It does disclose that a parent id creates a subtask and where to source member and tag ids, but it omits key mutation details such as required permissions, side effects (notifications, audit logs), error behavior, and what the operation returns.

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

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

The description is a single front-loaded sentence that states the core action immediately, followed by a compact enumeration of optional fields. Every clause earns its place and 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?

For a 10-parameter create tool with no annotations and no output schema, the description is adequate but incomplete. It covers most optional parameters and the subtask behavior, yet leaves out projectId and description, and provides no guidance on when to use the tool versus siblings or what happens after creation.

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 90%, so the schema already documents nearly all parameters in detail. The description repeats most of that information and adds the source tool for member ids (weeek_list_members), but it omits projectId and description parameters entirely. This slightly exceeds the schema but does not compensate for the small coverage gap.

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

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

The description opens with a specific verb and resource: 'Create a task.' That clearly identifies the operation and distinguishes it from siblings like list, update, and complete tasks, even without explicitly naming alternatives. The remainder lists optional placement and assignment details, reinforcing the create purpose.

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

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

The description gives no guidance on when to use this tool versus alternatives (e.g., weeek_update_task, weeek_create_board), nor does it state prerequisites or exclusions. It only enumerates optional parameter uses, which is not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the useful context that column ids are used to place tasks, but says nothing about permissions, read-only nature, or pagination/return behavior for what is a listing 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?

A single front-loaded sentence naming the action first, followed by the one piece of useful contextual guidance. No filler or redundancy.

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

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

For a simple one-parameter list tool this is close to adequate, but with no annotations and no output schema the description could disclose what the columns look like or what a column id is. It covers the essential call information but leaves return-value expectations unset.

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

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

There is a single parameter (boardId) with 100% schema description coverage, so the schema already documents it. The description adds no format or semantic detail beyond the schema, making the baseline of 3 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?

States a specific verb and resource ('List the columns of a board'), which is distinct from siblings like weeek_list_boards or weeek_list_tasks. It does not explicitly name a sibling it is not, but the resource is narrow enough to be 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 clause 'use a column id to place a task' hints at the downstream purpose of the returned data, which implies when an agent would need this tool. However, there is no explicit when-to-use vs alternative guidance or prerequisite information.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but the description says nothing about permissions, pagination, ordering, or rate limits, and only incidentally hints at output shape via '(id, name)'. That is thin for a tool with zero annotation coverage.

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

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

A single short sentence, front-loaded with the verb and resource, with zero filler. It is arguably too terse for its behavioral gaps, but as a sizing/structure judgment it is 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?

For a simple one-parameter read tool with no output schema, the description covers the core operation and sketches the return shape. It stops short of pagination/ordering behavior, but the tool's low complexity keeps the omission from being severe.

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 there is exactly one parameter, documented as 'Project id'. The description's '(id, name)' refers to returned fields, not the input, so it adds no parameter semantics beyond the schema. Baseline 3 applies.

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

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

States a specific verb (List) and resource (boards) with a clear scope qualifier (in a project) plus the projected fields (id, name). It doesn't explicitly contrast itself with siblings like weeek_list_board_columns or weeek_create_board, but the resource noun is distinct enough that an agent can route correctly.

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

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

No when-to-use, when-not-to-use, or alternative guidance. The only implicit signal is the required projectId and the 'in a project' scope. An agent must infer that this is the board-enumeration step before calling weeek_list_board_columns or weeek_list_tasks.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation but discloses nothing about pagination, result limits, ordering of comments, or permission requirements for a tool that queries another resource by id.

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

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

A single five-word sentence with the resource and operation front-loaded and zero filler. It is efficient, though so terse that it risks being under-specified rather than optimally concise.

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 read tool with 100% schema coverage, the description is minimally adequate. Since there is no output schema, an agent gets no hint about the shape or volume of returned comments, which is a real gap.

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

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

Schema description coverage is 100% for the single parameter (taskId: 'Task id'), so the schema already documents it. The description adds only the implicit relation that taskId identifies the task whose comments are returned, which is the baseline expectation rather than extra 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?

The description states a specific verb (List) and resource (a task's comments), which is enough to distinguish it from siblings like weeek_list_projects or weeek_add_comment. However, it does nothing to differentiate itself from the other list_* tools beyond the resource noun, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as weeek_list_tasks or weeek_add_comment, nor any stated preconditions (e.g., whether the task must exist or the caller needs access). The only implicit context is the pronoun 'a task's'.

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 implicitly signals a safe read by saying 'List' and discloses the returned fields, which is above the minimum. But it says nothing about permission requirements, pagination, or whether the result is scoped to the current workspace.

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

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

Two short sentences, zero filler, with the purpose front-loaded and the usage hint trailing. 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?

With no output schema and no annotations, the description usefully compensates by listing the returned fields. It is nearly complete for a trivial no-arg list tool; only pagination/scope behavior is unaddressed.

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 the baseline is 4. The description appropriately uses its space to describe the return shape rather than inventing parameter guidance.

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 ('List workspace members') and enumerates the returned fields (id, name, email, role), so the agent knows exactly what it gets. It does not explicitly differentiate itself from siblings like weeek_list_projects or weeek_list_tasks, but the resource noun makes confusion unlikely.

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 a member id as an assignee' hints at downstream usage, which is genuinely useful routing information. However, it never states when to call this versus other list tools, nor any prerequisites (auth scope, workspace 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?

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but nothing is stated about permissions/auth requirements, pagination, result ordering, or workspace scoping beyond a single phrase.

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

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

A single front-loaded sentence with no filler. Every word earns its place, though the brevity comes at the cost of detail captured in other dimensions.

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 list tool with no output schema, the description is minimally sufficient to call the tool. The gaps are the missing read-only/behavioral context (no annotations) and any hint about result shape or scope, which leave it merely adequate.

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 and the schema is empty, so there is nothing for the description to compensate for. Baseline 4 applies; no meaningful parameter meaning 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?

States a specific verb (List) and resource (projects) scoped to the workspace, which cleanly separates it from create/update siblings. It does not explicitly differentiate from its closest read siblings (weeek_list_boards, weeek_list_members), but the resource noun does the work.

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?

'List ... in the workspace' implies the enumeration use case, and the resource noun routes the agent away from the board/member/task listing siblings. However there is no explicit when-to-use guidance, no prerequisites, and no indication of how results relate to the other list tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. The verb 'List' implies a read-only operation, and the return fields are named, but there is no explicit statement about side effects, permissions, pagination, or workspace scoping beyond the word 'workspace'.

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?

It is a single, front-loaded sentence with no wasted words. The second clause is slightly cryptic but still concise; it could be clearer, keeping it from a full 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?

For a simple, zero-parameter list tool with no output schema, the description covers the core return fields (id, title) and hints at usage. It lacks notes on pagination or ordering, but those are minor for this complexity level.

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 input parameters, so there is nothing for the description to clarify. Baseline score of 4 applies for a parameterless tool.

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

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

The description states a specific verb ('List') and resource ('workspace tags'), and the parenthetical '(id, title)' clarifies the returned fields. It clearly distinguishes from siblings like weeek_list_projects or weeek_list_tasks by naming a different 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?

The clause 'pass a tag id to a task's tags' implies a downstream workflow, but it does not state when to call this tool versus alternatives or any prerequisites. Usage is only implicitly suggested by the mention of tag ID consumption.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no read-only confirmation (implied only by 'List'), no pagination behavior, no result limits, no default ordering, no auth requirements. For a list endpoint with zero annotation coverage this is a significant gap.

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

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

A single short sentence, front-loaded with the action and resource, with zero filler. It is efficient, though it is arguably under-specified rather than optimally concise.

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 read tool this covers the essentials of what it does, but with no output schema and no annotations the agent still lacks the return shape, pagination, and ordering information needed to call it confidently.

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

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

Schema description coverage is 100% for the single projectId parameter, so the schema already documents it. The description only confirms it is optional, adding no format or semantic detail beyond the structured field; baseline 3 applies.

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

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

States a specific verb (list) and resource (Weeek tasks) and notes the optional filter. It is distinguishable from siblings like weeek_list_projects or weeek_list_members because the resource is named, though it never explicitly contrasts itself with any alternative.

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 mentions an optional projectId filter but gives no guidance on when to use this tool versus other listing or task-related siblings, nor any prerequisites, pagination, or scope limits. Usage is only implied by the name.

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

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

No annotations are provided, so the description carries the full burden. It clarifies that duration is in minutes, but says nothing about permissions, whether entries are additive or replace existing time, or what happens on duplicate submissions for the same task/date/user.

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

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

Two short sentences, front-loaded with the action and followed by unit/source clarifications. Every clause earns its place 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 4-required-param mutation tool with no annotations and no output schema, the description is adequate but thin. It covers parameter basics while leaving behavioral questions (auth, reversibility, response) unaddressed.

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 minor value by restating the duration unit and naming the source of userId, but contributes no format or constraint detail beyond the schema.

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

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

The description states a specific verb+resource: logging a time entry on a task. It partially distinguishes itself from siblings by pointing to weeek_list_members as the source for userId, though it doesn't contrast with any other time-related 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?

It implies when to use it (logging time) and gives a concrete workflow hint that userId comes from weeek_list_members, but there is no explicit when-not guidance or comparison to alternatives.

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

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

With no annotations, the description carries the full burden. It does disclose genuinely important mutation semantics: assignees replace the list, other fields are PATCH-style. That is valuable beyond the schema (especially for assignees/tags). However, it says nothing about required permissions, whether omissions clear values, or error behavior on invalid ids.

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 operation and immediately followed by the one non-obvious behavioral rule (replace vs merge). 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 10-parameter mutation tool with no annotations and no output schema, the partial-update semantics are covered but several gaps remain: interplay with complete_task, behavior of undocumented fields, and what a successful update returns. Adequate but not sufficient for full confidence.

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 60%, with tags, taskId, dueDate, priority, assignees, and customFields already documented in the schema. The description reinforces the replace semantics for assignees but adds no meaning for the undocumented title, description, isCompleted, or boardColumnId 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 first sentence gives a specific verb+resource ('Update a task'), which is enough for an agent to know the operation. It does not distinguish itself from siblings like weeek_complete_task or weeek_create_task, which also mutate task 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?

There is no guidance on when to use this tool versus alternatives such as weeek_complete_task (which may be the idiomatic path for isCompleted) or weeek_create_task. No prerequisites or context are stated.

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