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

With no annotations, the description carries the full burden and does so well: it discloses that comments post as the calling user, that the body is Markdown, and critically that there is no public comments API, so it drives the web API through a browser session requiring WEEEK_EMAIL/WEEEK_PASSWORD or a cached login. It leaves out failure modes (expired session, permission errors) and any return value, keeping it short of a 5.

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

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

Three tight sentences, purpose front-loaded, then format, then the auth caveat. Each sentence earns its place; 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?

No output schema and no annotations, so the description must stand alone, and it covers purpose, body format, authorship, and the unusual auth requirement. It omits what the call returns (e.g., the new comment id) and error behavior, which keeps it from being fully 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 50%: text is documented ('Comment body as Markdown') but task_id has no schema description. The description enriches the text parameter by enumerating supported Markdown constructs, partially compensating, but says nothing about task_id's meaning or where to obtain it.

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+resource ('Comment on a task'), making the create-a-comment action clear. It does not explicitly differentiate from siblings like weeek_update_task_comment or weeek_delete_task_comment, but 'posts as you' implies creation rather than modification.

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

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

There is no when-to-use guidance and no routing to alternatives, even though the sibling list contains update_task_comment, delete_task_comment, and list_task_comments. The agent must infer that this tool always creates a new comment rather than modifying one.

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 discloses one useful trait (a task can belong to multiple projects, so this is additive and not destructive to other links), but says nothing about permissions, idempotency when the task is already in the project, validation of board_column_id, or error behavior for a 3-parameter mutation.

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 core action, and every clause carries information (the multi-project semantics and the optional column targeting). 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 small 3-parameter tool with no output schema and no annotations, the description covers the essential action but leaves gaps: it does not say what happens if the task is already in the project, whether the column must belong to the target project's board, or what a failure looks like. Adequate but incomplete.

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 there are three parameters, so the description must compensate. It maps all three loosely (task, project, optional board column) and marks board_column_id as optional and project-scoped, but adds no type, format, or required/optional precision beyond that.

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 ('Put a task into a project') and the parenthetical '(a task can live in several)' clarifies it is an additive link rather than a move, distinguishing it from weeek_move_task and weeek_remove_task_from_project. It does not name those siblings explicitly, so it stops short of a 5.

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

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

The phrase 'Optionally target a board column there' implies when to supply board_column_id, and the additive framing implies when to use this over a move. There is no explicit when-not guidance or prerequisite (e.g., project must exist, task must exist, column must belong to that board), so usage is only implied.

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. 'Mark a task complete' implies a mutation (changing task state), but doesn't disclose what side effects occur — e.g., whether completing a task affects subtasks, dependencies, timers (there's a weeek_task_timer sibling), or whether the operation is idempotent. An agent has no way to know what happens if the task is already complete.

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 an efficient single sentence with no wasted words. It's appropriately short for a simple operation. However, being concise is not the same as being complete — the brevity here is more under-specification than economy.

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

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

The tool is a simple single-parameter mutation, so complexity is low. However, it has no annotations, no output schema, and a 0% schema description coverage. A description of just 'Mark a task complete.' for a mutation tool that changes task state is insufficient — it should at least note whether the tool affects the task's status field, whether it's reversible (weeek_uncomplete_task exists implying reversibility), and what the return value is.

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%, meaning the schema provides no descriptions for the single required parameter task_id. The tool description adds zero information about what task_id is, its expected format, or how to find it. With only one parameter and no description, the description must compensate, but it doesn't.

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 'Mark a task complete.' uses a clear verb+resource (mark/task) with a specific action (completing). It's distinguishable from the sibling weeek_uncomplete_task which would be the inverse operation. However, it's fairly minimal and doesn't describe any nuances like whether it toggles state or what prerequisites exist.

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 guidance on when to use this tool versus alternatives. It's implicitly distinct from weeek_uncomplete_task (the opposite operation) and weeek_update_task (which may handle broader updates), but the description doesn't explicitly articulate these distinctions or mention any prerequisites like needing an agent to already have the task retrieved.

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

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

With no annotations, the description carries the full burden. It usefully discloses that dates are set separately and that board_column_id is normally required, which are non-obvious traits. However, it says nothing about permissions, failure modes, or what the call returns, leaving meaningful gaps for a mutation tool with zero annotation coverage.

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

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

Three compact sentences with no filler, front-loading the create action and then the key prerequisites and the date caveat. Every sentence carries actionable information.

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 output schema and no annotations, the description covers the essential prerequisites and the important date-handling quirk. Parameter details are largely carried by a 70%-covered schema, so it is reasonably complete, though it omits return/error behavior.

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 70%, and the schema itself documents day, priority, description, custom_fields, and board_column_id richly. The description adds the project_id/board_column_id requirements but little else, so it largely defers to the schema. Baseline for this coverage level is around 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?

The first sentence states a specific verb and resource ('Create a task'), which cleanly separates it from update/delete/move siblings. It also implies scope by tying creation to a project. It stops short of a fuller differentiation narrative, but the core purpose 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?

It tells the agent what is required (project_id), what is normally needed (board_column_id) and where to get it (weeek_list_board_columns), plus that dates must be set via weeek_update_task. This is real operational guidance. It lacks an explicit 'when not to use this' or a named alternative for other creation paths, so it is not a full 5.

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 states it deletes a task (implying destructive/irreversible behavior) but doesn't disclose whether the operation is cascade-deleting related entities, whether it removes timers/attachments/subtasks, or whether any confirmation or permission is required. For a destructive operation, this is a significant transparency 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?

The description is a single, focused sentence with zero wasted words. It front-loads the action ('Delete a task') and provides the identifying mechanism ('by id'). Every word earns its place, though arguably it could add behavioral caveats, but the instruction here is about conciseness, and this is exemplary.

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?

This is a destructive mutation tool with no annotations, no output schema, and 0% schema coverage. The description should compensate by disclosing side effects, irreversibility, and related resources affected (attachments, watchers, time entries, assignees). It does none of that. For a delete operation of this consequence, the single-sentence description is inadequate.

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 mentions 'by id' which aligns with the single required task_id parameter, but with 0% schema coverage, the schema provides no description. However, with only one simple integer parameter and its purpose clearly stated, the description's implication of 'provide the task id to identify which task' adds sufficient meaning. The description doesn't add format or validation details beyond the schema, but the low complexity keeps this at an acceptable middle score.

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

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

The description uses a specific verb+resource ('Delete a task by id'), clearly distinguishing this from siblings like weeek_complete_task, weeek_update_task, and weeek_uncomplete_task. The purpose is clear, though it doesn't explicitly differentiate from the other task-management siblings, making it a solid but not exemplary score.

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

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

No when-to-use guidance is provided. The description doesn't state when deletion is appropriate, prerequisites (e.g., task must exist), or contrast with alternatives like weeek_complete_task or weeek_uncomplete_task. The context of deleting vs. merely altering task state is left entirely to the agent's 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?

No annotations are provided, so the description carries the full burden, and it does disclose the single most important trait: deletion is permanent with no trash or recovery path. It omits permission requirements and confirmation/response behavior, which keeps it out of 5 territory.

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, no filler, with the irreversible-deletion warning front-loaded ahead of the sibling alternative. Every clause carries distinct information.

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

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

For a two-parameter destructive tool with no output schema, the description covers the essentials: what disappears permanently, which sibling to use instead for edits, and where the ID originates. Only authorization and failure-mode context is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially: it tells the agent that comment_id comes from weeek_list_task_comments. However, task_id is left entirely unexplained, and neither typing nor format nuance beyond the schema is added.

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 ('Delete a comment') with an unambiguous scope qualifier ('for good — Weeek keeps no trash'). It explicitly names the sibling it is not (weeek_update_task_comment), so an agent can separate deletion from editing without opening either schema.

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

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

Gives an explicit alternative and the condition that selects it: 'To fix wording, prefer weeek_update_task_comment.' It also routes the agent to weeek_list_task_comments to obtain the identifier. It stops short of stating general when-not conditions (e.g. bulk cleanup, permissions), so it 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool returns metadata and a download URL, but doesn't disclose whether this is a pure read operation with no side effects, whether authentication or specific permissions are required, or what happens if the file_id is invalid or unauthorized. Given zero annotation coverage, more transparency is expected.

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 efficient sentence with no wasted words. It front-loads the verb and resource. The brevity is appropriate given the tool's simple single-parameter interface.

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?

This is a simple single-parameter retrieval tool with no output schema and no annotations. Given the absence of both, the description should at least describe what the returned metadata contains or how the download URL is used. Instead it stops at the bare minimum. It is functional but leaves the agent without clarity on return format or follow-up usage of the download URL.

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 only mentions 'file id' as the input. The input schema only provides the parameter name 'file_id' with type string and no helper text. The description does not clarify the format or origin of the file_id (e.g., whether it comes from a list attachments call), leaving the agent to infer the meaning from the name alone. This is the minimum needed to use the tool, but no value is added 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 the verb ('get') and resource ('one attachment'), and specifies it returns metadata and download URL by file id. It distinguishes itself from weeek_upload_attachment (which does the opposite operation) and from list-type tools. However, it doesn't explicitly compare against siblings, relying on the name (weeek_get_attachment) to carry 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention that it requires a prior upload or list call to obtain the file_id, nor does it contrast with weeek_upload_attachment or other attachment-related operations. Context for obtaining the file_id parameter is entirely absent.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Get' implies a read operation, but the description doesn't state whether the returned object includes all fields, whether it returns an error when the id doesn't exist, or any other behavioral properties (auth requirements, rate limits). It adds essentially no behavioral information beyond the schema.

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

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

The description is a single short sentence that takes minimal space. However, this borders on under-specification rather than deliberate conciseness — there's no additional detail, so it reads more like a tautological placeholder than an efficiently structured description. Still, 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?

For a single-ID fetch tool with no output schema and no annotations, the description is notably thin. It doesn't explain what the task object contains, whether it includes custom fields, subtasks, or relationships, or how it differs from list operations. While a get-by-id tool is conceptually simple, the absence of any return-format or behavior detail leaves the agent guessing about the response shape.

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

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

Schema description coverage is 0%, but the description's single parameter (task_id) is self-explanatory in both the name and the schema type. The description doesn't add anything about the semantics of task_id beyond what the schema shows — no mention of format constraints, valid range, or where to obtain a task_id (e.g., from weeek_list_tasks). With only one parameter that's self-evidently an ID, the description adds zero value here.

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

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

The description states 'Get one task by id' with a clear verb (Get) and resource (task), identifying this as a retrieval operation. It's minimally distinguishable from sibling weeek_list_tasks and weeek_get_attachment, but the singular 'one' and 'by id' does set it apart as a single-item fetch. Purpose is clear but thin, not explaining what fields or scope are returned.

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 guidance on when to use this tool versus alternatives like weeek_list_tasks (list all) or weeek_get_attachment (get attachment file). There's no mention of when a task wasn't provided in list results, or that this is the way to fetch full details for a single task. The agent must infer from the tool name and sibling set rather than from the description.

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. The description doesn't state whether this is a read-only operation, what the response format looks like, whether columns are returned in a specific order, or whether the operation requires specific permissions. For a listing tool with zero annotation coverage, this is a notable gap.

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

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

Two short sentences with no filler. The parenthetical clarification that columns are 'statuses' is genuinely useful terminology mapping. The tool is simple enough (1 param) that this level of brevity is appropriate, and there's minimal 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 list tool with a single required parameter, this is nearly adequate. The description explains the resource and the required parameter. However, the lack of output schema, no annotations, and no mention of related error cases or pagination behavior leave some gaps. The tool is simple enough that these gaps are somewhat tolerable, but a note about what 'columns' returns and their relationship to tasks would improve completeness.

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 only 1 parameter at 0% schema description coverage, the description should compensate. The description does mention that board_id is required by the Weeek API, which reinforces the schema's required field declaration, but adds little beyond what the input schema already states about board_id being required. It doesn't explain what a valid board_id is or how to obtain it.

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 'List board columns (statuses) for a board' which uses a specific verb (list) and resource (board columns), clarifying that columns are synonymous with statuses. However, it doesn't distinguish itself clearly from sibling tools like weeek_list_boards or weeek_manage_board_columns, though the verb+resource distinction is somewhat implied by the naming convention.

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

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

No when-to-use guidance is provided. The description only notes that board_id is required, which is a parameter constraint rather than usage context. There's no mention of when this tool should be preferred over weeek_manage_board_columns, which relates to the same resource with a different verb, nor any prerequisites like needing to list boards first to get a valid board_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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. "List" clearly implies a read-only operation, which is a positive signal, and "of a project" scopes the operation to a single project. However, it doesn't disclose what happens with an invalid project_id, whether the response includes both board statuses/types, or any pagination/ordering behavior. For a read-only list tool, the disclosure is adequate but minimal.

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?

Five words exactly cover the purpose with zero filler. For a simple single-parameter list tool, this level of conciseness is appropriate and commendable. No wasted sentences, no redundant elaboration.

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, read-only list tool with no output schema and no nested objects, the description is nearly complete. The main gap is that it doesn't hint at the return structure (board names, IDs, statuses) or the prerequisite of obtaining a project_id first. But given the tool's simplicity and the sibling relationships in the same family (all weeek_list_* follow a predictable pattern), the description is largely sufficient.

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. The description identifies project_id as the scoping filter (boards belonging to a project), which provides some semantic meaning. However, it doesn't specify whether project_id refers to the ID from weeek_list_projects or whether any format constraints apply. With only 1 parameter and the description naming 'project' as the scope, the bare minimum is met.

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?

"List boards of a project" uses a specific verb (list) + resource (boards) + scope (of a project). It clearly distinguishes from sibling tools like weeek_list_projects (listing projects) and weeek_manage_boards (managing boards). Could be slightly more specific about what a board represents, but the purpose is clear and 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?

No guidance is given on when to use this tool versus alternatives like weeek_list_board_columns or weeek_manage_boards. The description simply states what it does without context on selection criteria. It does, however, clearly indicate that project_id is required, implying it must be fetched first (likely via weeek_list_projects), but this prerequisite is not stated explicitly.

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

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

No annotations are provided, so the description carries full burden. It transparently discloses the notable behavioral quirk that results may include fields belonging to other projects (since tasks list every workspace field), and warns that writing to those is reported as an error. This is honest, non-obvious, and highly valuable behavioral context beyond any schema.

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

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

Three sentences, all earning their place. Each sentence adds distinct value: what it lists, why the workaround exists, and the caveat about cross-project fields. Slightly dense but nothing wasteful — 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 single-parameter listing tool with no output schema, this description covers the important essentials: what's returned, the empty-project edge case, how the data is sourced, and the cross-project caveat. There is no output schema to compensate, so the description carries full completeness burden and does so well.

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 (project_id) exists, and the description names 'project' as the scope. Schema coverage is 0%, so the description compensates by clarifying semantics: it's a project-scoped read. However, it doesn't specify the exact format/type of project_id, though this is minor given the tool's self-contained single param.

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?

Clear verb+resource+scope: 'List the task custom fields visible in a project' with the exact fields returned (id, name, type, select options). Distinguishes from siblings: it's the read counterpart to weeek_manage_custom_fields, and it's clearly a listing tool (not a whoami/member/project lister).

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 the critical limitation: 'a project with no tasks yet returns nothing' — a key condition agents must know before invoking. Also explains the workaround mechanism (reads fields off a task because no schema endpoint exists) and the consequence of writing to other-project fields (reported as an error).

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 doesn't mention whether this is read-only, what happens on error, or return format details. Listing is implicitly read-only but this is never stated. Being a list tool, the risk profile is relatively low, but there's no explicit statement.

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 concise sentence that states the action, the returned fields, and a practical pointer (use ids as assignees). Zero wasted words. Ideal structure for a parameterless list 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 parameterless list tool, the description is reasonably complete. It names the output fields and gives usage guidance. However, it doesn't describe pagination, sorting, or whether the list may be large, and given no output schema exists, it could benefit from a bit more detail on return structure. Still adequate for the tool's simplicity.

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 0 parameters, and schema coverage is 100%, meaning there's nothing the description needs to document. With no params, the dimension imposes no burden. The description covers the full scope since the tool takes no 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?

Clear verb+resource: lists workspace members. Identifies returned fields (id, name, email) which adds specificity. Distinguishes from siblings (weeek_list_projects, weeek_list_boards deal with other resources), though it doesn't explicitly name them.

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

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

The description implies the tool is used to obtain member ids for assignment purposes ('use their ids as assignees'), which provides a use case context. However, it doesn't explicitly state when to use this vs alternatives (e.g., weeek_whoami or other member-related tools). The usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the burden. 'List' clearly signals a read operation (non-destructive, no mutation), which is accurate given the tool's read-oriented nature. However, it doesn't disclose behavioral details like return format, pagination, error cases, or whether authentication is required — though for a simple list tool with zero parameters, the risk is minimal.

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 perfectly sized — verb, resource, scope, and output fields in nine words. Zero waste, no filler, fully front-loaded. An exemplar of conciseness.

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, no-output-schema listing tool, the description is nearly complete. It covers what it lists (projects), scope (all), and output fields (id, name). The only gaps are minor: no mention of pagination or authorization requirements, but these are unlikely to be critical for a simple read-only list of projects.

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, so there are no parameter semantics to document. The description correctly notes the output fields (id, name), which is the most relevant semantic information an agent needs. With no parameters, the baseline of 4 applies, and the field disclosure adds value.

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 'List all task-manager projects (id, name)' uses a specific verb (List) with clear resource (projects) and scope (all), explicitly stating the returned fields (id, name). It distinguishes clearly from siblings like weeek_manage_projects (which handles mutations) and other list tools targeting different resources (boards, members, 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?

The description implies this is a read-oriented listing operation via the 'List all' phrasing, but provides no explicit guidance on when to use it versus alternatives. It doesn't name sibling alternatives (such as weeek_list_boards or weeek_manage_projects) or state when-not-to-use it, though the read/list orientation is reasonably clear from 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals the sort order (oldest first) and the fields returned (author, text), which is real behavioral value, but it says nothing about pagination/limits, whether deleted comments are included, or any permission 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?

A single front-loaded sentence with zero filler; the verb, scope, ordering, and return payload are all packed in without repetition.

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

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

For a simple one-parameter read with no output schema and no annotations, the description covers the essentials — what is listed, in what order, and what each item contains. Pagination or result-size behavior is the only notable 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 0%, so the schema documents nothing beyond the type. The phrase "a task's comments" confirms task_id identifies the parent task whose comments are fetched, but adds no format, range, or sourcing detail beyond the self-explanatory name.

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 a task's comments") and even adds scope details: ordering (oldest first) and the returned fields (author, text). It is clearly distinguishable from the sibling write operations add_task_comment, update_task_comment and delete_task_comment, though it never names them explicitly.

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

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

There is no when-to-use guidance, no prerequisite statement, and no mention of alternatives such as weeek_get_task or the comment mutation tools. The read intent is only implied by the verb "List", leaving the agent to infer 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?

No annotations exist, so the description carries full behavioral burden, yet it discloses almost nothing beyond 'list'. It says nothing about pagination semantics (despite offset/per_page params), result limits, sort order, or whether results span projects/workspaces.

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

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

A single front-loaded sentence with zero padding; the purpose and filter list are delivered immediately with 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?

For a 14-parameter query tool with no annotations and no output schema, the description is far too thin. It should at least clarify pagination, default result scope, and the date/priority/type filters that the schema documents poorly.

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

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

Schema coverage is only 36% and the description only paraphrases a subset of filter names (project, board, column, assignee, completion, tags, text search), mapping loosely to project_id, board_id, board_column_id, user_id, completed, tags, search. It ignores day, type, start_date, end_date, priority, offset and per_page, leaving nearly half the parameters explained nowhere.

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 (tasks) with the filter scope enumerated. It clearly distinguishes itself from mutation siblings like create_task/update_task by the read-only verb, but it never names an alternative sibling such as get_task for single-task retrieval.

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 word 'optional filters' implies the usage context (breadth-first retrieval), so intent is inferable. However, there is no explicit when-to-use vs get_task, no guidance on combining filters, and no statement about default behavior when no filters are given.

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 bears full behavioral burden. It doesn't disclose authorization requirements, whether delete is permanent, what happens to tasks in a deleted column, or whether reordering affects other boards. Only the basic CRUD verbs are stated.

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 with zero waste. The main purpose is front-loaded and the guidance note follows immediately.

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

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

For a mutation tool with no annotations and no output schema, the description is under-specified. It doesn't cover permissions, side effects (especially for delete/move), error behaviors, or what the response contains. The schema covers parameters, but behavioral context is largely missing.

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

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

Schema description coverage is 80%, which is high, so the schema already documents most parameters (name, board_id, board_column_id, upper_board_column_id). The description only implies the action modes but adds no syntax or edge-case detail beyond what the schema provides, setting the baseline at 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?

The description clearly states a specific verb set (create, rename, delete, reorder) and the resource (board column / status). It names a sibling read tool, weeek_list_board_columns, creating some differentiation, though it doesn't distinguish itself from other manage-style tools as sharply as possible.

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 second sentence explicitly points to weeek_list_board_columns for reading, which is a clear alternative. However, it doesn't state when to prefer this tool's create vs update vs delete vs move actions beyond the schema enum, leaving some usage inference to the agent.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that delete is destructive/irreversible, what happens to a board's columns or tasks on deletion, permission requirements, or reorder side effects — significant gaps for a mutating tool. It only names the operations.

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

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

Two short sentences, zero waste, with the operation set front-loaded and the read alternative trailing. Appropriately sized for the tool.

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

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

The schema is relatively rich (per-action required params at 80% coverage), which offsets some of the burden. But with no annotations and no output schema for a mutation tool, the absence of any destructive-effect or permission disclosure leaves the behavioral picture incomplete.

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 80%, so the schema already documents name, board_id, project_id, and upper_board_id per action. The description adds no format, constraint, or edge-case detail beyond what the schema provides, so the 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?

States specific verbs (create, rename, delete, reorder) against a specific resource (board), and explicitly names the sibling weeek_list_boards as the read counterpart. Minor terminology drift ("rename"/"reorder" vs the enum values "update"/"move") slightly blurs the exact action set, keeping it 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?

Provides an explicit alternative for reading ("Use weeek_list_boards to read them"), so the agent knows which tool handles reads versus mutations. It does not, however, state when to prefer each action or any prerequisites/exclusions for the mutating paths.

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

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

No annotations are provided, so the description carries the burden. It clarifies the ownership/scope semantics (which is genuine behavioral context beyond the schema), but doesn't address auth/required permissions, side effects of transfer (what happens to existing task data), reversibility, or response behavior. Given no annotations, this is a moderate disclosure that could go further.

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 compact 3 sentences with the key concept (scope) front-loaded. It's efficient but packs in a lot without explicit structure; the action-to-param mappings are implied via schema descriptions rather than enumerated. Slightly dense for a complex 13-param, 9-action 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?

This is a genuinely complex tool: 13 params, 9 actions in an enum, nested objects, multiple scopes, and per-action parameter requirements. With no output schema and no annotations, the description would need to spell out which params apply to which action to be fully complete. The scope explanation helps but the action-specific parameter requirements are left implicit in the schema, making the description incomplete for an agent to confidently drive this high-complexity tool.

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

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

Schema description coverage is high at 92%, so the schema already documents most parameters. The description adds the scope model explanation (scope + scope_id relationship) which goes beyond the schema's 'Where the field lives.' However, with 13 parameters and only ~92% covered, the description doesn't compensate for the undocumented remainder, and doesn't explain the action-to-parameter matrix (which params are needed per 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 lists specific verbs (Create, update, delete, move or transfer) tied to a clear resource (custom fields and their select options). It also adds the scope concept (board/project/global) that distinguishes this tool from siblings like weeek_list_custom_fields, and even names that reader tool explicitly.

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

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

The description explains the scope model (field belongs to one board, project, or global, set scope and scope_id accordingly), which is a crucial usage condition. It also calls out weeek_list_custom_fields as the reader for what a project's tasks show. However, it doesn't explicitly state when NOT to use this vs other manage_* tools or provide negative 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. It implies a destructive delete but says nothing about what happens to projects inside a deleted portfolio, whether nesting via parent_id is validated, or what permissions are required — a significant gap for a delete-capable 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?

One sentence, front-loaded with the action set, and the parenthetical definition of 'portfolio' earns its place by disambiguating from the project tools. Zero 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 7-parameter multi-action CRUD tool with no annotations and no output schema, the description is minimum viable: it names the operations but omits 'get', gives no return or pagination context for list, and no delete side effects. An agent could call it, but not 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 86%, so the schema already documents name, portfolio_id, limit, offset, search and parent_id. The description adds no syntax, format, or interaction detail beyond what the schema provides, so 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 specific verbs (list, create, rename, delete) against a named resource and defines the resource parenthetically as 'the folders projects live in', which separates it from siblings like weeek_manage_projects. It loses a point because the action enum includes 'get' and 'update' but the description only names 'rename'/'delete', so one supported action goes unmentioned.

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

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

No when-to-use guidance, no prerequisites, and no named alternative among the many sibling manage_* tools. The only routing signal is the verb list itself, leaving the agent to infer the context from the action enum.

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 entire burden of behavioral disclosure. It lists the action types but doesn't disclose side effects: what happens to tasks in an archived project, whether delete is permanent or reversible, permission requirements, or whether dependent resources get cascaded. For a mutation tool with five distinct destructive/non-destructive actions, 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?

Two efficient sentences, zero filler. Front-loaded with the full action list and immediately points to the read sibling. Could arguably add one sentence of behavioral context (e.g., 'Archive and delete have different task implications'), but overall it's well-structured and skimmable.

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?

This is a complex multi-action CRUD tool (5 actions) with no output schema and no annotations, yet the description is a single-line action list. It doesn't clarify return values per action, prerequisites (e.g., portfolio_id required for create), or the distinct semantic weight of archive vs unarchive vs delete. For a tool of this complexity, the description under-delivers on the behavioral contract, though schema descriptions offset some of 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?

Schema coverage is 71%, so most parameters (name, color, project_id, is_private, action, portfolio_id) have their own descriptions. The tool description adds no beyond-schema value for parameters. The description adds the 'Required on update' nuance for color, but that's already in the schema. Baseline 3 is appropriate since schema handles most of the work, though the ~29% undocumented remainder (description param) is a minor 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?

Clear action verb 'Create, update, delete, archive or unarchive' with explicit resource 'a project'. Distinguishes from sibling read tool weeek_list_projects. Purpose is well defined and unambiguous, though it doesn't enumerate all operations' effects distinctly.

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?

Description explicitly points to weeek_list_projects for reads, establishing a clear read-vs-write boundary. However, it doesn't provide exclusions for when NOT to use this tool vs other manage_* siblings (tags, boards, columns, portfolios), nor scenarios like when project deletion is preferable to archiving.

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 behavioral disclosure burden. The description identifies the four operations, which implies mutation for create/update/delete. However, it doesn't disclose side effects, whether deletion is permanent/destructive, permissions required, or how the rename/recolor behavior interacts with tasks that use the tags. For a mutation tool with zero annotations, this is somewhat 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 description is a single compact sentence that efficiently enumerates the four operations and includes an embedded pointer to a related tool (weeek_update_task). It's front-loaded with the key purpose and uses no filler. Slightly more detail could be added about conditionality of parameters, but for its length 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?

With no annotations, no output schema, and a multi-action tool covering four different operations with conditional parameters, the description is adequate but not rich. It tells the agent what actions exist but not the full conditional logic (e.g., which parameters are required per action beyond what's implied), nor what the list output looks like for the downstream use case. Given the tool's complexity (4 actions with varying parameter requirements), more context would help.

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 75%, and the schema already describes title (required for create/update), tag_id (required for update/delete), and color (required on update). The description adds minor value by clarifying that list provides tag ids for downstream use in weeek_update_task, but overall the schema carries most of the parameter meaning. Adequate baseline given good 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 the tool manages workspace tags with four operations (list, create, rename/recolor, delete). The verb 'manage' plus the enumerated operations is reasonably specific, and the note about listing tags with ids for use in weeek_update_task adds sibling differentiation value. It's clear but 'manage' is still slightly generic compared to a tool name that might incorporate the operations directly.

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

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

The description implies the use cases by enumerating the four actions, and mentions that list output provides ids for use in weeek_update_task. However, it does not explicitly state when to use this tool vs alternatives (e.g., vs weeek_manage_custom_fields or other config tools), nor does it provide any exclusions or when-not-to-use guidance. Some context is present but no explicit 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?

No annotations are provided, so the description carries the full burden. It's a mutation tool (log/edit/delete) but doesn't disclose side effects, whether changes are reversible, that update must target an existing entry, or if permissions are required. It does NOT contradict annotations since none exist, so no contradiction flag.

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 concise sentence that covers the main operations and critical parameter requirements in clear prose. It's efficient without excess. Could arguably front-load the delete action, but overall tight.

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?

This is a 7-parameter mutation tool with no annotations and no output schema. It's an action-dispatching tool covering three distinct behaviors (create/update/delete) with different required fields. The description should explain behavioral differences per action, return behavior, and edge cases, but only states parameter requirements. For a multi-action CRUD tool with 57% schema coverage, this is inadequate.

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 57%, covering date, user_id, duration, entry_id, and is_overtime. The description adds action-specific parameter requirements (create/update vs delete), which is useful beyond the schema. However, it doesn't clarify is_overtime semantics or how duration/date interact. Baseline 3 with the action-routing info marginally adding value.

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 can log time on a task, or edit/delete a logged entry. It uses a clear verb+resource structure (log/edit/delete time entries). However, it doesn't explicitly distinguish from sibling tools like weeek_task_timer, though the names are reasonably distinct.

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 specifies which parameters each action needs ('create and update need user_id, date, duration; delete needs entry_id'), giving helpful action-specific guidance. However, it doesn't provide when-to-use vs alternatives context or any exclusions. The usage guidance is action-routing rather than alternative-selection 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. The description states the mutating behavior (move), which is clear, but it doesn't disclose whether the move is reversible, what happens to the task's position in the column, whether board_id is applied before column_id as a dependency (the schema does hint this), or what the response looks like. For a mutation tool with zero annotations, more disclosure is needed.

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 efficient sentence that states the core purpose and the key usage constraint. It's appropriately sized, though it could benefit from a brief note on parameter relationships without bloating.

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 3 parameters, schema coverage at 33%, no output schema, and no annotations, this is a moderately complex mutation tool. The description covers purpose and the key constraint (at least one of two params), but lacks behavioral details like ordering semantics, reversibility, or return behavior. It's adequate but leaves gaps for a tool with 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?

Only 1 of 3 parameters (board_id) has schema description coverage (33%), so the description must compensate for board_column_id and task_id. The description implies the board_column_id is the destination column and mentions the relationship between the two parameters, but it doesn't explain what numeric values are valid or how task_id relates. The description adds minimal value 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 the verb+resource: 'Move a task to a board column (status) and/or to another board.' This distinguishes it from siblings like update_task (general updates), complete_task, and delete_task. It's specific about moving, though it could be slightly clearer on what 'status' means in the weeek 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 a partial usage constraint: 'Give at least one of board_column_id, board_id.' This clarifies when to use it logically. However, it doesn't explicitly distinguish when to use this tool vs update_task or add_task_to_project, nor does it mention any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove' implies mutation, but there's no mention of whether this is reversible, whether it requires specific permissions, whether removing the last assignee has side effects, or what the response looks like. For an unannotated mutation tool, 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 clear sentence, zero wasted words. However, being concise is not the same as being sufficient; the one-liner under-delivers on the detail an agent needs.

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

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

With 2 required parameters at 0% schema coverage, no output schema, and no annotations, the single-sentence description is wholly inadequate. The agent cannot determine what format 'assignees' takes, whether partial removal is possible, or what happens after invocation. For a mutation tool with zero structured support, this is completely underspecified.

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 there are no descriptions in the schema JSON for 'task_id' or 'assignees'. The description's mention of 'assignees' loosely maps to the parameter but adds no semantic depth. The 'assignees' array of strings is ambiguous — it's unclear if these are member IDs, names, or emails, since the schema gives no hint.

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 'Remove assignees from a task' states a clear verb (remove) and resource (assignees from a task). It distinguishes from siblings like set_assignees (which adds/assigns), but it's minimally stated with no additional scope or context about which task system or limitations.

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 guidance on when to use this tool versus alternatives. There's no mention of when to use remove_assignees vs set_assignees (which could replace the full assignee set), no prerequisites, and no context about whether this partially or fully clears assignees. The sibling set_assignees creates ambiguity that isn't addressed.

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. The description doesn't state side effects (does removing from a project affect task data? assignments? is it reversible?), whether it requires specific permissions, or what the response looks like. For a mutating operation 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?

The description is a single efficient sentence with no wasted words. It's appropriately concise for a simple operation, though it could arguably be slightly more informative without losing this conciseness.

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 mutating operation with no annotations, no output schema, and 0% schema coverage, the description should do more heavy lifting. It doesn't explain behavior when the task belongs to only one project, whether errors occur on invalid project_id, or any side effects. The description is minimally sufficient for basic understanding but incomplete for safe usage.

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 two parameters (task_id, project_id) are completely undocumented except for their names and types. The parameter names are fairly self-explanatory, but the description adds essentially no semantic value beyond what the schema provides. The description gives no context on what these IDs refer to or how they relate.

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 'Remove a task from one of the projects it belongs to' uses a specific verb (remove) and resource (task from project). It distinguishes from siblings like weeek_add_task_to_project and weeek_delete_task (which deletes the task entirely), so the purpose is clear and well-differentiated.

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

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

The description implies the task belongs to multiple projects ('one of the projects it belongs to'), which gives context on when to use it. However, it provides no explicit guidance on when NOT to use it versus alternatives like weeek_delete_task, and doesn't clarify what happens if a task belongs to only one 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove watchers' implies a mutating operation, but there's no statement about whether the task must exist, what happens with invalid watcher IDs, error behavior for unknown watchers, or whether the operation is idempotent.

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

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

A single efficient sentence with zero waste. It's appropriately minimal, though the brevity comes at the cost of the missing explanatory content noted 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?

With no annotations, no output schema, and 0% parameter coverage, this description is thin for a mutating tool. It doesn't address failure modes, idempotency, required permission/authentication context, or relation to the sibling set_watchers tool. The watchers array format ambiguity is a significant gap for a tool that needs correct inputs to avoid errors.

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 undocumented parameters. It doesn't explain what format watchers should take (member IDs, emails, usernames), nor does it clarify what type the task_id values are beyond the schema's integer type. The 'watchers' array semantics (strings — are these emails or user IDs?) are entirely unclear.

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 ('Remove watchers from a task'), which clearly identifies the action. However, it doesn't distinguish itself from the sibling tool weeek_set_watchers, leaving ambiguity about how these differ in their watcher-manipulation semantics.

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 guidance is provided about when to use this tool versus the closely related weeek_set_watchers or weeek_remove_assignees. The description gives no context on when removal is appropriate, prerequisites, or exclusion criteria.

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. 'Add assignees' implies a mutation, but the description does not state whether this appends to existing assignees or replaces them, whether it requires specific permissions, whether it's reversible, or what the response looks like.

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 concise sentence with zero waste. However, it may be slightly under-specified rather than optimally concise, though the brevity is acceptable.

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, this description is thin. It lacks behavioral detail (append vs. replace semantics), permission requirements, return value expectations, and any error conditions. The reference to weeek_list_members is useful but insufficient for full completeness.

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 only mentions that member ids come from weeek_list_members. The description does hint that assignees values are member ids (which maps to the array of strings param), but does not elaborate on the task_id format or any constraints on the assignees array.

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 ('Add') and resource ('assignees to a task'), clearly stating what the tool does. It also references 'weeek_list_members' as the source of member ids, which differentiates it from the sibling 'weeek_remove_assignees'.

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

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

The description implies usage context by referencing 'weeek_list_members' as the source of member ids, but it does not explicitly state when to use this vs. alternatives like weeek_remove_assignees or weeek_set_watchers. No exclusions or prerequisites are given.

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 does disclose that parent_id null detaches the task and that after/before control sibling placement, which is useful mutation context. However, it omits permissions, reversibility, conflict handling when both after and before are supplied, and other side effects expected for a write 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?

The description is two short sentences with no wasted words, and it front-loads the core operation before the ordering detail. Every phrase contributes to understanding the tool.

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

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

For a mutation tool with no annotations, no output schema, and one undocumented required parameter, the description is minimally adequate. It explains the core hierarchy and ordering behavior but provides no guidance on when to use it versus alternatives or how errors and edge cases are handled.

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 75%, with parent_id, after, and before already documented in the schema. The description adds only the combined behavior of nesting/detaching and sibling placement, and it does not document task_id, the one parameter lacking a schema description. It therefore adds marginal value beyond the structured 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: 'Nest a task under another one, or detach it with parent_id null.' It also mentions ordering via after/before. However, it does not explicitly distinguish this tool from similar siblings like weeek_move_task, so it falls short of the top score for 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 implies usage scenarios (nesting, detaching with null, ordering among siblings) but gives no explicit when-to-use guidance, no exclusions, and no alternatives. The agent can infer the basic case but gets no routing help against similar sibling 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 burden. It mentions 'Add' which implies mutation, but doesn't disclose whether adding is additive (appends) or replaces existing watchers, whether duplicates are handled, permissions required, or what happens on invalid member ids. For a mutation tool this is a meaningful gap.

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

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

The description is a single efficient sentence with zero filler. It packs the core purpose and a cross-tool reference into minimal 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?

For a 2-parameter mutation tool with no annotations and no output schema, this description is thin. It doesn't explain behavioral semantics (append vs replace), error handling, return value, or required permissions. The watchers source reference helps but doesn't compensate for the missing behavioral and completeness detail.

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

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

Schema description coverage is 0%, and the description only explains where watcher ids come from (weeek_list_members). It adds nothing about what task_id means or the format/semantics of the watchers array items beyond what the schema already implies (string items). The description partially compensates for the lack of schema detail on the watchers param but leaves task_id undocumented.

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 (Add) and resource (watchers/subscribers to a task). It also references the source of member ids (weeek_list_members), adding useful context. It doesn't explicitly distinguish from the sibling weeek_remove_watchers, though the contrasting verb is implied in the name.

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

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

The description provides context on where member ids come from (weeek_list_members), which hints at usage prerequisites. However, it doesn't explicitly state when to use this vs. alternatives like weeek_remove_watchers or weeek_set_assignees, and gives no exclusion guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals this is a mutating tool (start/stop) but does not state whether calling 'stop' on a non-running timer is harmless, whether 'start' on an already-running timer resets or ignores, what side effects occur (e.g., creating a time entry), or whether permissions are required.

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, concise sentence with zero waste. It is appropriately front-loaded and immediately conveys the core function.

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 tool has no annotations and no output schema, and there is a closely-related sibling (weeek_manage_time_entry) creating ambiguity. For a mutating tool, the description should clarify behavior on edge cases (double-start, double-stop), whether timers are per-user or per-task, and how it differs from the time entry management tool. This is meaningfully incomplete.

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, but it provides no parameter documentation beyond what the schema already contains. The two parameters (task_id, action) are self-explanatory from their names, and the enum makes 'action' clear, so the baseline is reasonable, but no additional semantics are added to justify a higher score.

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

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

The description 'Start or stop the running timer on a task' clearly states the verb (start/stop) and resource (task timer), matching the action and task_id parameters. However, it doesn't meaningfully differentiate from the related weeek_manage_time_entry sibling, which may be the more appropriate tool for some timer 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?

There is no guidance on when to use this tool versus the closely-related weeek_manage_time_entry, nor are exclusions or prerequisites given. The description implies usage context ('running timer on a task') but does not state whether timers time-track against a project or whether starting requires an existing time entry.

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. However, the description is minimal and doesn't explain behavioral traits such as whether it's a mutating operation (it clearly is), what happens if the task is already incomplete, error states, or side effects. 'Mark as not complete' is self-evident but lacks depth on edge behaviors.

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 concise sentence that fully captures the action. There is zero wasted text, and the brevity is appropriate for a simple single-purpose 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 mutating tool with one parameter and a clear purpose, the description is almost adequate. However, with no annotations, no output schema, and no parameter documentation, it falls slightly short—it might benefit from noting error conditions (e.g., task not found or already incomplete) or the reverse relationship to weeek_complete_task. Still, the minimal footprint makes this close to sufficient.

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

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

There is only one parameter (task_id, an integer). Schema description coverage is 0%, so the description doesn't compensate with parameter details. However, with a single obvious integer parameter to identify the task, the schema itself is largely sufficient. The description adds no parameter semantics but the need is minimal.

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 'Mark a completed task as not complete' clearly states the verb (mark) and resource (completed task). It's the inverse of weeek_complete_task, which is evident from the sibling list. While it could be more specific about context, the purpose 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?

No guidance is given on when to use this tool versus alternatives. It implicitly complements weeek_complete_task, but the description doesn't directly reference when one should be used over another, nor does it mention any prerequisites (e.g., task must currently be completed for it to make sense).

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: it does not say whether this is a partial merge (omitted fields left intact) or a full replace, what permissions or session it needs, whether clearing values is possible, or what the response contains. The one genuinely notable behavior — that the description is written over a collaborative channel and needs a knowledge base session — lives in the schema, not the 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?

A single front-loaded sentence with the verb and resource first, then the enumerated surface. Nothing is wasted, though the parenthetical list is partly redundant 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?

With 12 parameters, a nested custom_fields object, no annotations, and no output schema, the definition is thin on the update-semantics dimension — partial vs. full update and error/failure behavior are unaddressed. The schema fills in parameter-level detail, which keeps this from being incomplete, but the description should say more about how the mutation behaves.

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 75%, above the baseline, and the schema itself carries rich parameter detail (priority label mapping, tag id sourcing, custom_fields keying and error behavior, empty-string clearing). The description's parenthetical field list largely restates what the schema already documents, so it adds marginal meaning beyond the structured 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 ('Update') and resource ('a task') and enumerates the editable surface: fields, custom field values, and description. It is clear what the tool does, though it never distinguishes itself from specialized siblings like weeek_set_assignees, weeek_move_task, or weeek_complete_task that also mutate a 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing away from the many sibling mutation tools (assignees, watchers, timers, completion, move, delete). The agent must infer that this is the general field-update path from the field list alone.

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

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

No annotations, so the description carries the full burden. It discloses useful behavior: the comment is rewritten in place (old text is replaced, not appended), and the 'one of your comments' phrasing hints at an ownership constraint. It says nothing about required permissions, behavior on non-owned/missing comments, or whether the update is reversible, leaving real gaps for a mutation 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?

Two tight sentences, front-loaded with the action and the key behavioral nuance, then the identifier provenance. Every clause earns its place with no redundancy.

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

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

No output schema and no annotations, and one of three parameters (task_id) is undocumented anywhere. For a simple in-place edit this is close to adequate, but an agent still lacks permission/ownership semantics and any indication of what the call returns.

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

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

Schema coverage is only 33%; only 'text' is documented (as Markdown). The description compensates partially by explaining that comment_id must come from weeek_list_task_comments, but task_id is left with no semantic explanation in either place. Baseline-plus-value but not full compensation.

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 (rewrite) and resource (one of your comments), and clarifies the key semantic difference from posting a new comment: the edit happens in place. It does not explicitly name the sibling tools (weeek_add_task_comment / weeek_delete_task_comment), but the 'instead of posting a correction' framing makes the distinction inferable.

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 a clear when-to-use condition: fix an existing comment rather than appending a correction. It also tells the agent where comment_id comes from (weeek_list_task_comments), which routes it to the right prerequisite call. No explicit when-not guidance or named alternative, so not a 5.

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. Beyond noting paths must exist locally, it doesn't disclose what happens on failure, whether attachments replace or add to existing files, size limits, permissions required, or the return format. For a write tool with zero annotation coverage, this is a notable gap.

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

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

Two short sentences with zero wasted words. Every sentence earns its place, and the 'Paths must exist on this machine' caveat is a high-value operational detail. 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?

For a simple 2-parameter tool with no output schema and no annotations, the description is close to adequate. It covers both parameters' purpose and a key operational constraint. However, it omits behavioral context like what happens on failure, confirmation of successful upload, or whether attachments are additive, which would help complete the picture for a write operation.

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

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

Schema coverage is 50%: paths has 'Absolute file paths' described while task_id has none. The description confirms paths must be local and exist, adding a small operational detail. It doesn't explain the task_id format or validity requirements beyond what the schema's type 'integer' conveys, so it adds marginal value but doesn't fully compensate for the 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 clearly states the verb ('Attach') and resource ('local files to a task'), which is specific and distinct from siblings like get_attachment or move_task. However, it doesn't explicitly contrast with sibling tools, though the attachment name and description make the purpose evident.

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

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

The description implies usage ('Attach local files to a task') but gives no explicit when-to-use vs alternatives guidance. It does note 'Paths must exist on this machine,' which is a useful operational prerequisite, but there are no exclusions or alternative tool references.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The description correctly implies a read-only operation without stating it explicitly. It doesn't mention potential failure modes like invalid tokens, but for a simple identity lookup, the behavioral expectations are reasonably clear.

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, both highly informative. The first states the purpose and return shape; the second provides practical usage context. Zero 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?

For a zero-parameter, no-output-schema read-only tool, the description is essentially complete. It specifies the return values (id, name), the authentication source (API token), and a practical use case. There's little more it could add without being verbose.

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 100% schema coverage (empty object), so there's nothing for the description to explain. The baseline of 4 for no-param tools is appropriate here; the description adds the return content hint (id, name) which 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 returns the current user (id, name) based on the API token. It uses specific verbs and identifies the resource. It doesn't explicitly distinguish from siblings, but among list/manage tasks, this is a self-identifying action.

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 includes practical guidance: 'Useful to get your userId for assignments.' This tells the agent a concrete use case, though it doesn't explicitly name alternatives or when-not-to-use. For a whoami-style tool, the purpose is self-evident.

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