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

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. Description adds that reactions are lower-cased automatically and provides error codes, adding context beyond annotations.

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

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

Well-structured with clear sections, an example, and error handling. Every sentence adds value without being verbose.

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

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

Given the tool's simplicity, annotations, and presence of an output schema, the description covers purpose, usage, parameters, and errors adequately.

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

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

The input schema already has descriptions for each parameter. The description adds useful context like lower-casing behavior and default workspace, but schema coverage is high.

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

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

The description clearly states 'Add an emoji reaction to a Chat message.' It uses a specific verb-resource pair and distinguishes from sibling tools like clickup_delete_chat_reaction and clickup_get_chat_message_reactions.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections with specific alternative tool names. Error handling details further guide usage.

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

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

The description explains the dependency creation behavior in detail, including direction mutual exclusivity, required parameters, and return value. It also covers error handling (400/403/404) for common issues. Annotations are non-contradictory and the description adds significant behavioral context beyond them.

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

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

The description is well-organized with clear sections, front-loaded with the core purpose, and each sentence adds value. It is concise yet comprehensive, with no fluff.

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

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

Given the presence of an output schema (confirmation), the description appropriately mentions the return value. It also covers error handling and provides examples, making it complete for an agent to use effectively.

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

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

Despite context indicating 0% schema description coverage, the description adds essential parameter semantics: explains mutual exclusivity of depends_on/dependency_of, clarifies custom_task_ids usage, and gives concrete examples. This compensates fully for any schema gaps.

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

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

The description clearly states the action: 'Create a blocking dependency between two tasks.' It explains the concept of dependency direction and distinguishes from related tools like clickup_add_task_link and clickup_delete_dependency, ensuring the agent understands exactly what this tool does.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear context: enforce execution order or surface blockers, and contrast with clickup_add_task_link for loose associations and clickup_delete_dependency for removal. Examples further guide correct usage.

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

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

Annotations already indicate non-readonly and non-destructive mutation. Description adds that the guest gains visibility into every list and task in the folder, that Enterprise plan is required (403 error), and that confirmation or error string is returned. This goes beyond annotations to clarify exact behavior and constraints.

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

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

Description is concise, well-structured with clear sections (purpose, when to use/not use, returns, example, errors). Every sentence adds necessary information without redundancy.

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

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

For a tool with 4 parameters and an output schema, the description covers purpose, constraints (Enterprise plan), alternatives, error handling, and return format. It is fully adequate for an agent to select and invoke correctly.

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

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

Schema has parameter descriptions, but description adds value by clarifying permission_level meanings (e.g., read=view) and providing a usage example. The include_shared parameter is not elaborated, but overall adds nuance beyond schema.

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

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

Description clearly states the tool shares a folder with an existing guest at a given permission level. It distinguishes from siblings by specifying folder-level access versus list or task, fulfilling a specific verb+resource purpose.

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

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

Explicitly states when to use (giving guest access to entire folder) and when not to use (use list or task alternatives). Also notes Enterprise plan restriction and provides error handling details, giving clear guidance on appropriate usage context.

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

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

Discloses important behavioral aspects beyond annotations: the guest gains visibility into every task, Enterprise plan requirement (403 on other plans), and specific error codes (403, 404). Annotations already indicate mutability (readOnlyHint=false), but description adds significant context.

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?

Well-structured with clear headers (When to Use, When NOT to Use, Returns, Examples, Error Handling). Front-loaded with purpose. Every sentence adds value, no fluff.

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

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

Covers essential aspects: purpose, usage guidelines, enterprise limitation, error handling, sibling differentiation, and an example. Missing explicit mention of the include_shared parameter, but output schema exists for response details. Slight gap in not explaining that the guest must already exist.

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 does not explain all parameters in detail. It provides an example showing list_id, guest_id, and permission_level, but omits the optional include_shared parameter entirely. Schema description coverage is 0%, so description should compensate more. However, the example clarifies usage of the required parameters.

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

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

The description clearly states the tool shares a List with an existing guest at a given permission level, specifying that the guest gains visibility into every task. It explicitly differentiates from siblings by naming alternatives in the 'When NOT to Use' section.

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

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

Provides explicit 'When to Use' and 'When NOT to Use' sections, with clear references to sibling tools (clickup_add_guest_to_task, clickup_add_guest_to_folder) and a note about Enterprise plan restriction.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, but the description adds valuable context: returns a confirmation string or error string, explains error handling for 403 and 404, and notes that it is a mutation but not destructive. This goes beyond the bare annotations.

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

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

The description is well-organized with clear sections (purpose, prerequisites, when to use/not use, returns, examples, error handling). It is concise yet comprehensive, 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?

Given the tool's complexity (permission levels, guest prerequisite, plan restriction, error handling), the description covers all essential aspects: purpose, prerequisites, usage conditions, return value, error handling, and examples. It references sibling tools and includes sufficient detail for correct invocation.

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

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

Schema description coverage is 0%, but the description adds value through examples showing usage of custom_task_ids and team_id, and clarifies permission_level enum values ('read (view), comment, edit, or create (full access)'). This compensates for the lack of 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 'Share a single task with an existing guest at a given permission level.' It specifies the action (share), resource (task), and recipient (existing guest), and distinguishes itself from sibling tools like clickup_add_guest_to_list and clickup_add_guest_to_folder by emphasizing a single 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?

The description includes explicit 'When to Use' and 'When NOT to Use' sections, directs to alternative tools for list/folder sharing, and states prerequisites (guest must exist via clickup_invite_guest_to_workspace) and plan restrictions (Enterprise only).

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

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

Annotations already show it's a write operation (readOnlyHint: false), idempotent (idempotentHint: true), and non-destructive (destructiveHint: false). The description adds context about returning a confirmation string, error handling (404 if tag/task missing), and that the tag must exist. No contradiction with annotations.

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

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

The description is well-structured with clear sections (purpose, when to use/not, returns, examples, error handling). Every sentence is informative, no redundancy, and front-loaded with the main action.

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

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

Given the moderate complexity (4 parameters, no output schema, good annotations), the description covers purpose, prerequisites, usage guidance, examples, and error handling comprehensively. It is self-contained and sufficient for correct tool 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?

The input schema already describes parameters with clear descriptions. The description adds value through practical examples that demonstrate usage of all parameters, including optional ones like team_id and custom_task_ids, and explains fallback behavior for team_id.

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 'Apply an existing Space tag to a task,' using a specific verb and resource. It distinguishes from sibling tools like clickup_create_space_tag (for creating tags) and clickup_remove_tag_from_task (for removal).

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 explicit 'When to Use' and 'When NOT to Use' sections, directing users to clickup_create_space_tag for creating new tags. It also states the prerequisite that the tag must already exist.

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

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

Annotations indicate it's a write operation (readOnlyHint=false) and non-idempotent, but the description adds valuable behavioral context: only task-to-task links are supported, returns a confirmation naming both tasks, and explains 404 error handling. This goes beyond what annotations alone provide.

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

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

The description is well-organized with clear sections (purpose, when to use/not, returns, examples, error handling). Every sentence is informative and no word is wasted, making it 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?

Given an output schema exists, the description wisely summarizes the return type without over-explaining. It covers error handling and constraints (task-to-task only). However, it omits details like idempotency or rate limits, but these are partially covered by annotations.

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

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

The input schema already provides descriptions for all parameters (100% coverage despite context signal), so the description adds limited extra semantic value. It covers the non-blocking nature and error conditions but does not significantly enhance parameter understanding.

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 'Link two tasks with a non-blocking "related to" association', specifying the action, resource, and linkage type. It distinguishes itself from siblings like clickup_add_dependency by emphasizing the non-blocking nature.

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 explicit 'When to Use' and 'When NOT to Use' sections, providing clear context for when this tool is appropriate and directing the user to clickup_add_dependency for completion order enforcement.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds critical behavioral context: requires specific ClickApp, does not move the task, returns confirmation or error string, and details error handling for 403 and 404.

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 well-structured with clear sections (description, prerequisites, when to use/not use, returns, examples, error handling). Every sentence is informative and 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?

Given the tool's complexity (requires a ClickApp, has a specific behavior distinct from move), the description covers all necessary aspects: prerequisite, use cases, alternatives, return format, and error handling. It is complete for an agent to use correctly.

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

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

The input schema already provides descriptions for list_id and task_id. The description adds an example and mentions that the task stays in its original list, but does not elaborate further on parameter semantics. Since schema covers the parameters, the description adds moderate 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 it adds an existing task to an additional list, distinguishes from moving a task, and notes it does not duplicate but adds membership. It is specific and differentiates from sibling tools like clickup_add_guest_to_list or clickup_add_tag_to_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?

Explicit 'When to Use' and 'When NOT to Use' sections with an alternative (move-task tool) and prerequisite (Tasks in Multiple Lists ClickApp). Provides clear guidance on when to invoke this tool vs 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?

Annotations already provide hints (readOnlyHint=false, idempotentHint=true). The description adds value with error handling (404) and implicit tag creation behavior. However, it does not fully describe idempotency implications or other side effects, leaving minor gaps.

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 well-structured with clear sections (purpose, endpoint, siblings, usage, returns, examples, error handling). It is concise and front-loaded with essential 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?

Given the presence of an output schema and thorough error handling, the description covers all essential aspects. It is complete for effective tool invocation.

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

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

The schema itself has detailed descriptions for each parameter, so the tool description does not need to repeat them. However, with 0% coverage from the description, it offers only an example that ties parameters together. This is adequate but not excellent.

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

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

The description clearly states the action (apply tags to time entries), specifies the endpoint, and distinguishes from sibling tools (remove and rename). It also provides usage context for bulk-tagging and implicit tag creation.

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

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

Explicitly states when to use (bulk-tagging, new tag) and when not to use (single entry editing via clickup_update_time_entry), offering a clear alternative. This meets the highest standard.

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

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

The description states that if a channel with the given name already exists, the tool returns the existing channel instead of creating a duplicate, which is idempotent behavior. However, the annotation idempotentHint=false directly contradicts this, causing confusion about the tool's actual behavior.

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

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

The description is well-structured with clear sections (main description, usage, examples, errors) and is concise without extraneous information. Every sentence serves a purpose.

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

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

The description covers usage guidelines, alternatives, return format, error handling, and defaults (e.g., workspace_id). While very thorough, the contradiction with idempotent hint creates a completeness issue, though the description itself is otherwise 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?

The input schema already provides descriptions for all parameters, so the description does not need to repeat them. However, it adds value by giving concrete examples and clarifying the 'name' parameter's duplicate-handling behavior, which goes 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 tool creates a Workspace-level Chat channel by name, distinguishing it from location channels and direct messages. The verb 'create' and resource 'chat channel' are specific, and sibling differentiation is explicit.

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

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

The description includes explicit 'When to Use' and 'When NOT to Use' sections, naming alternatives like clickup_create_location_chat_channel and clickup_create_direct_message. It also explains the idempotent behavior of returning existing channels, providing excellent guidance.

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

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

Annotations already indicate it's a write operation (readOnlyHint=false). Description adds concrete return format (id, hist_id, timestamp) and error handling (404 meaning). Does not detail side effects beyond creation.

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

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

Front-loaded with main action, then logically organized into endpoint, when to use, returns, example, and error handling. No unnecessary 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?

Provides enough context with legacy vs new API distinction, return format, error handling, and example. Could be more explicit about response structure but text description suffices.

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

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

Schema already provides descriptions for all parameters (100% coverage). Description includes an example but adds no new meaning 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?

Explicitly states it posts a comment into a Chat view and distinguishes from the newer chat message tool (clickup_send_chat_message). Clear verb and resource.

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

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

Dedicated 'When to Use' and 'When NOT to Use' sections with explicit alternative tool name and scenario.

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

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

The description adds behavioral context beyond annotations: it states the checklist is empty initially, explains error codes (404, 403) and their meanings, and specifies the return format (confirmation string with name and id). This is valuable context not covered by annotations alone.

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 highly structured with sections (When to Use, When NOT to Use, Returns, Examples, Error Handling) that are concise and valuable. Every sentence adds information, and the main action is front-loaded.

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

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

Given the tool's moderate complexity (task ID variants, team ID fallback, error handling, relation to other tools), the description covers all essential aspects: purpose, usage boundaries, return type, examples, and error conditions. It is fully adequate for an agent to invoke correctly.

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

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

Although the schema descriptions cover parameter basics, the description enriches semantics with usage examples showing different parameter combinations (e.g., custom_task_ids fallback to CLICKUP_TEAM_ID). It also clarifies the team_id requirement when custom_task_ids is True, which is not explicit in 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 tool adds an empty checklist to a task, with a specific verb ('Add') and resource ('checklist'). It distinguishes from the sibling tool clickup_create_checklist_item by noting that items are added afterwards, making the purpose unambiguous.

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

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

The description explicitly defines when to use (breaking a task into trackable sub-steps) and when NOT to use (for work requiring assignee/due date/status, with the alternative clickup_create_task with parent). This provides clear guidance for tool selection.

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

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

Annotations indicate non-read-only, non-destructive, non-idempotent. The description adds details on return format (confirmation string with optional id) and error handling (404, 400), supplementing annotations well.

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

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

Well-structured with clear sections and examples, though slightly verbose. Front-loaded with purpose, but every sentence contributes value.

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

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

Covers usage, alternatives, errors, and return format. With a simple schema and output schema provided, the description is sufficiently complete for an agent to use correctly.

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

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

Schema descriptions already cover parameter meanings. The description's examples illustrate usage but do not add significant semantic depth beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states 'Add a new line item to an existing checklist,' which is a specific verb+resource. It distinguishes from siblings like clickup_create_checklist by focusing on adding an item to an existing checklist.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear context, including naming the alternative tool clickup_create_checklist for creating the checklist itself.

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

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

The description adds context about the tool being idempotent in behavior (returns existing DM if same participant set), which is at odds with the annotation 'idempotentHint: false'. This contradiction reduces reliability. Otherwise, it provides error handling details but no additional behavioral traits beyond what annotations already indicate (readOnlyHint=false, destructiveHint=false).

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

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

The description is well-structured with clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling). It is front-loaded with the main purpose. Although somewhat lengthy, every sentence contributes useful 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?

The description covers all key aspects: different DM types, participant limits, idempotency (existing channel returned), error codes, and examples. An output schema exists, so return value explanation is unnecessary. The description is thorough for this tool's 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?

The description adds value for 'user_ids' by explaining 1:1, Group, and Self DM scenarios with examples. However, 'workspace_id' is not mentioned in the description; the schema already adequately describes it. Since schema description coverage is effectively high (the schema contains descriptions for both parameters), the description adds moderate 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 action ('Create (or return)') and resource ('direct-message Chat channel') and specifies the limit of 15 users. It distinguishes from sibling tools 'clickup_create_chat_channel' and 'clickup_create_location_chat_channel' by mentioning they are for named or location-bound channels.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear guidance, including specific alternative tools to use instead. This helps the agent select the correct tool.

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

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

The description explains the placement behavior (optional parent_id/parent_type) and default location. It also describes error responses. Annotations do not contradict; the tool's behaviors are fully disclosed.

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

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

The description is concise, well-structured with clear sections, and front-loads the primary action. Every sentence adds value without redundancy.

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

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

Given the tool's parameter count and complexity, the description is complete: it covers usage, placement logic, alternatives, returns, error handling, and examples. Output schema is said to exist, so return values are covered.

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 descriptions already provide meaning for each parameter. The description adds valuable context like the numeric enum mapping for parent_type and the default behavior for missing parent fields, enhancing understanding beyond schema.

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

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

The description clearly states the tool creates a Doc, optionally placing it in a specific location. It distinguishes from siblings like clickup_create_page and clickup_edit_page.

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 explicit 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools. Examples and error handling further guide correct usage.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with the write operation. The description adds context: it posts multipart/form-data, returns id and URL (never bytes), and notes that some plans may 404. It does not explicitly mention file size limits or cleanup behavior, but overall adds good transparency beyond annotations.

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

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

The description is well-organized with sections for purpose, mechanism, usage guidance, return value, examples, and error handling. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (binary entity_type, dependency on another tool, error cases), the description covers all necessary aspects: the upload process, required follow-up for custom fields, return values, and error scenarios. It is complete for an agent to use correctly.

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

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

The input schema already describes each parameter, but the description adds crucial context: the distinction between entity_type 'attachments' vs 'custom_fields', that file_path must be local, and the post-upload step for custom fields using `clickup_set_custom_field_value`. Examples further clarify usage, compensating for any schema gaps.

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 uploads a local file to a task or File-type Custom Field (v3). It distinguishes itself from siblings like `clickup_create_task_attachment` (modern replacement) and `clickup_get_entity_attachments` (for reading), making the purpose unambiguous.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections name alternatives and provide fallback guidance. Error handling explains when to use `clickup_create_task_attachment` if the endpoint returns 404, leaving no ambiguity.

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

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

Annotations already indicate non-read-only and non-destructive nature; description adds context that the folder starts empty, only accepts name initially, and returns a confirmation string or error, without contradicting annotations.

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

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

The description is well-structured with sections, front-loaded purpose, and includes example and error handling. While slightly long, it remains useful and focused.

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

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

Covers purpose, usage, behavioral details, parameters, return value, error handling, and related tools, making it fully contextual for a simple creation 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?

The description reinforces the schema parameters with context about the API endpoint and an example. Though schema coverage is marked as 0%, the description adds value beyond the schema's minimal descriptions.

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

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

The description clearly states the action 'Create a Folder inside a Space' and differentiates from sibling tools like clickup_create_folder_from_template and folderless list tool, with explicit 'When NOT to Use' section.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections, plus a tip about enabling folder-level statuses via clickup_update_folder, providing clear guidance on when to select this tool over alternatives.

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

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

Discloses async behavior when return_immediately is default, suggests re-checking with clickup_get_folder. No contradiction with annotations.

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

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

Well-organized with sections, examples, and error handling. Slightly lengthy but each part adds value.

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

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

Covers use cases, async behavior, error codes, return type, and provides an example. Output schema exists but description adequately explains return value.

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

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

Description does not elaborate on parameters beyond schema; schema has detailed descriptions so burden is shared, but description adds minimal param insight.

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 creates a new Folder from a template, and distinguishes it from clickup_create_folder for plain empty folders.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections, with direct reference to sibling tool clickup_create_folder, and prerequisite mention of clickup_get_folder_templates.

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

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

Description discloses return format (confirmation or error string), error handling (404, 400), and lack of folder parent. Annotations are sparse (no readOnlyHint, destructiveHint), so description adds meaningful behavioral context, though no mention of side effects or auth.

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?

Well-structured with clear sections, front-loaded with purpose, and concise without unnecessary 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?

Covers all key aspects: purpose, usage conditions, alternatives, return format, examples, error cases. Output schema exists but description aligns with it. Complete for a creation 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?

Description provides examples for space_id, name, and optional status but does not explain other parameters (content, assignee, due_date, etc.). Input schema already has detailed parameter descriptions, so description adds marginal extra 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 tool creates a list directly in a space without a parent folder, using specific verb and resource. It distinguishes from sibling tools like clickup_create_list and clickup_create_list_from_template_in_space.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections with named alternatives (clickup_create_list, clickup_create_list_from_template_in_space) provide clear context for tool selection.

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

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

Annotations are present (readOnlyHint=false, destructiveHint=false). Description adds return type (confirmation string with id, name, type, or error string) and error handling (404 meaning wrong folder_id). Does not contradict annotations. Could mention any side effects, but creation tools typically have minimal side effects beyond creating the view.

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?

Very concise and well-structured with clear sections: purpose, when to use, when not to use, returns, example, error handling. Every sentence adds value with no redundancy.

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

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

For a creation tool with a comprehensive schema and existing annotations, the description covers usage context, error cases, and return format. Output schema is noted as present, so return details are sufficiently covered. No gaps identified.

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 descriptions cover all parameters (schema_description_coverage is high, though context says 0% it appears descriptions are present). The description provides a concrete example of required parameters (folder_id, name, type). This adds value over schema alone but does not detail optional parameters.

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

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

Clearly states 'Create a task or page view scoped to a Folder.' Differentiates from sibling tools by specifying when NOT to use and naming alternatives (clickup_create_space_view, clickup_create_team_view, clickup_create_list_view).

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 provides 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools for other scopes. This gives clear selection 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?

Annotations already indicate a non-read-only, non-destructive operation. The description adds context on grouping key results, return value, and error scenarios, but does not elaborate on open-world implications or rate limits.

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?

Well-organized and concise: purpose, relationship to other tools, usage guidance, return type, example, and error handling, all in a few sentences.

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

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

Given the presence of an output schema and rich annotations, the description covers all necessary context: action, usage, alternatives, errors, and an example, making it 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?

The schema already provides descriptions for all parameters, and the function description adds an example but no additional semantic meaning beyond what the schema offers.

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

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

The description clearly states the verb 'Create' and the resource 'Goal' in a Workspace, and distinguishes from related tools like clickup_create_key_result and clickup_update_goal.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections, including specific alternative tool names and error handling codes, providing clear guidance.

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

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

Annotations indicate a mutable but non-destructive operation. The description adds context by explaining type-specific behaviors (e.g., 'automatic' requires task_ids/list_ids) and error codes (404, 400). It does not cover authorization or side effects, but the main behavioral traits are disclosed.

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 well-structured with clear sections: header, type explanation, usage guidance, return info, example, and error handling. Every sentence adds value, and the format is front-loaded for quick understanding.

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

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

Given the complexity of multiple key result types and parameter dependencies, the description covers essential aspects: type semantics, when to use automatic, error conditions, and return value shape. The presence of an output schema (acknowledged but not shown) does not detract from the 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?

Although the input schema already has comprehensive descriptions (despite the 0% coverage signal), the description adds value by explaining the role of 'type' in progress tracking and the dependency of 'automatic' on task_ids/list_ids. The example further clarifies parameter usage.

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

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

The description clearly states 'Add a Key Result (Target) to a Goal,' using a specific verb and resource. It differentiates from sibling tools by explicitly noting that updating is handled by 'clickup_edit_key_result.'

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

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

It provides explicit when-to-use ('Breaking a Goal down into one or more measurable targets') and when-not-to-use ('Updating an existing Key Result's progress') with an alternative tool. Error handling details further guide correct usage.

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

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

The description explains inheritance of Folder statuses, clarifies that the 'status' parameter is a color not a task status, details error handling, and specifies the return format. It does not contradict annotations, which are 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 well-structured with sections for purpose, inheritance, when/not, return, examples, and errors. It is informative without being overly verbose, though some sentences could be tightened.

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

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

The description covers purpose, usage guidelines, parameter semantics, return type, and error codes. It lacks explicit mention of permissions or rate limits, but these are not critical for this simple creation tool and are implied.

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?

Given 0% schema description coverage, the description compensates by providing examples and clarifying parameter behavior (e.g., status as color, content vs. markdown_content), adding value beyond the schema's own descriptions.

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

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

The description clearly states the tool creates a new List inside a Folder, and distinguishes it from sibling tools like clickup_create_folderless_list and clickup_create_list_from_template_in_folder.

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 explicit 'When to Use' and 'When NOT to Use' sections, referencing concrete scenarios and alternative tools, providing excellent guidance for an AI agent.

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

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

The description clearly discloses the tool's behavior: it creates a comment (write operation) and returns a confirmation string or error. It details possible error responses for 404 and 403. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. No contradictions. The description adds valuable context beyond annotations.

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

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

The description is tightly organized with clear sections: single action line, HTTP endpoint, usage conditions, return format, example, and error handling. Every sentence serves a purpose, no redundancy. It is front-loaded and efficiently scannable.

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

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

Given the presence of an output schema, the description adequately explains the return format (confirmation with id, hist_id, timestamp) and error strings. Usage context (list vs. task comment) is clarified, and error codes are provided. All necessary information for invocation is covered without relying on external references.

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

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

The input schema fully describes all parameters with detailed descriptions. The free-text description provides an example but does not elaborate on parameter semantics beyond what the schema offers. Schema description coverage is 0% (description doesn't explicitly list parameters), but the schema compensates. The example adds marginal value, so a baseline of 3 is appropriate.

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

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

The description begins with 'Add a comment to a List's info panel,' which clearly states the verb and resource. It immediately distinguishes from commenting on a task by specifying 'not on an individual task' and referencing the sibling tool clickup_create_task_comment. The purpose is unambiguous and 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?

Explicit 'When to Use' and 'When NOT to Use' sections are provided. 'When to Use' gives a concrete example (status update visible to all). 'When NOT to Use' identifies the alternative precisely. Error handling hints further guide correct usage. This is exemplary 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?

Discloses async behavior with return_immediately parameter, background population for large templates, and error handling for 400 and 404. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false).

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

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

Well-organized with sections, examples, and error handling. Front-loaded with main purpose. Every sentence adds value; no unnecessary 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?

Covers all aspects: creation, async behavior, prerequisites (template discovery), error handling, and output format. Output schema exists and description explains return value. Complete 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?

Schema descriptions exist (e.g., for template_id, return_immediately), but description adds value by explaining template_id prefix, return_immediately default behavior, and the options parameter. With 0% schema coverage (per context), description compensates well. However, could be more concise about options.

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

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

Clearly states 'Create a new List inside a Folder by instantiating a List template.' with specific verb and resource. Distinguishes from siblings by mentioning alternative tools in 'When NOT to Use' section.

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?

Includes explicit 'When to Use' and 'When NOT to Use' sections with references to sibling tools like clickup_create_list_from_template_in_space and clickup_create_list. Also advises polling with clickup_get_list for large templates.

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

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

Annotations indicate a write operation (readOnlyHint false) and not destructive. The description adds key behavioral details: with return_immediately=True, the returned List id may represent a List still being populated in the background for large templates, and recommends polling with clickup_get_list to confirm completion. Also covers error handling.

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 well-structured with clear sections: purpose, prerequisites, usage guidelines, return value, examples, and error handling. Every sentence adds value, and it is concise without unnecessary 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?

Given no output schema, the description adequately explains the return value (confirmation string with id or error). It includes prerequisites, behavioral notes on background population, and error codes. The tool's complexity is well-covered.

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

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

The input schema already describes all parameters with descriptions. The tool description adds context for template_id (prefix) and return_immediately (effect), but does not detail the options parameter; however, the schema covers it. Overall, the description complements the schema well.

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 creates a new folderless List inside a Space by instantiating a template. It distinguishes from siblings by naming alternatives like clickup_create_list_from_template_in_folder and clickup_create_folderless_list, and provides specific use cases.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear context. It specifies scaffolding a folderless List with a known template, and warns against using when the space uses folders or when no template fits, directing to alternative 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that it returns a confirmation string with view id/name/type or an error, and mentions 404 error handling. No contradictions, but could further detail side effects (e.g., whether it modifies existing data).

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 well-structured with clear sections, examples, and bullet points. It is mostly concise, though the 'Returns' and 'Error Handling' sections could be slightly more compressed. Front-loaded with purpose and usage.

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

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

Given that an output schema exists and the schema describes parameters well, the description covers when to use, when not, return type, and error handling. It misses explaining all optional parameters, but the schema fills that gap. Overall 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. It provides an example with 'list_id', 'name', 'type' but does not explain all parameters in detail. The schema itself has descriptions for each property, and the example adds practical context, but the description doesn't fully cover the optional parameters' semantics.

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

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

The description clearly states it creates a view scoped to a List, with specific verb and resource. It explicitly distinguishes from sibling tools for Folder-, Space-, or Team-wide views, leaving no ambiguity.

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

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

The description provides explicit 'When to Use' and 'When NOT to Use' sections, naming alternative tools (clickup_create_folder_view, clickup_create_space_view, clickup_create_team_view) and clear conditions.

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

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

Annotations already indicate write operation (readOnlyHint=false) and non-destructive nature. Description adds useful behavioral context: name derivation, error handling (400, 404), and return confirmation structure.

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?

Efficient structure with separate sections for purpose, usage guidance, returns, examples, and error handling. Every sentence contributes meaning without redundancy.

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

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

Covers primary behavior, differentiation from siblings, parameter constraints, return value, and error scenarios. With an output schema present, the description provides sufficient context for correct tool selection and invocation.

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

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

Schema has detailed descriptions for all parameters. Description adds value by explaining the combined location object format and the absence of a name field. Examples illustrate usage patterns.

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 clearly 'Create a Chat channel bound to a Space, Folder, or List.' Distinguishes from sibling tools like clickup_create_chat_channel (standalone) and clickup_create_direct_message (DM) through explicit when-not-to-use sections.

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 defines when to use (give a location its own conversation) and when not to (standalone channel, DM) with alternative tool names. Provides examples for clarity.

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

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

Annotations indicate this is a write operation (readOnlyHint=false) but non-destructive (destructiveHint=false). The description adds that it returns a confirmation with name and id, and explains error handling for 404. This goes beyond annotations, though it could mention any required permissions or rate limits.

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

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

The description is concise and well-organized with clear sections: main action, when to use, when not to use, returns, examples, and error handling. Every sentence adds value.

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

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

Given the output schema exists (context signals), the description appropriately covers return behavior and error scenarios. Examples cover both top-level and nested page creation. All essential decision points are addressed.

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

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

The input schema provides detailed descriptions for all 7 parameters (name, doc_id, content, etc.), so the description doesn't need to repeat them. The description adds useful examples showing typical usage patterns, which helps the agent understand how to combine parameters.

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

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

The description clearly states the verb 'Add a page to an existing Doc' and specifies optional nesting. It distinguishes from siblings like clickup_create_doc and clickup_edit_page in the 'When NOT to Use' section.

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 states when to use ('To append a new section/page to a Doc you already created or found') and when not to use, with references to alternative tools for creation and modification.

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

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

Annotations already indicate readOnlyHint=false (write) and destructiveHint=false. Description adds that custom statuses are silently ignored and error codes for auth/validation, which is valuable beyond annotations.

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

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

Well-structured with sections and front-loaded. Could be slightly more concise, but every section adds value.

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

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

Covers purpose, usage, limitations (statuses), returns, and errors. Adequate for a creation tool with rich annotations and output schema.

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

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

Schema description coverage is 0% (context signal), so description must compensate. It mentions 'features' and gives an example, but does not systematically describe each parameter. The schema itself has detailed descriptions, but the tool description adds marginal 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?

Clearly states 'Create a new Space inside a Workspace' with specific verb and resource. Distinguishes from siblings by explicitly naming when to use folder/list tools and update_space instead.

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

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

Provides explicit 'When to Use' and 'When NOT to Use' sections, with specific alternatives mentioned (folders/lists tools, update_space, ClickUp UI).

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

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

The description adds value beyond annotations by specifying the return type (confirmation string) and error handling (404 for nonexistent space, 400 for duplicate tag). Annotations do not contradict, and the description provides useful behavioral context even though openWorldHint=true.

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 well-structured with clear sections: summary, usage guidelines, return info, examples, and error handling. It is concise with no wasted words, front-loading the key action.

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

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

The description fully covers what the tool does, when to use it, what it returns, and common errors. It is complete for a tag creation tool with good sibling differentiation.

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

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

The schema descriptions cover parameters well, and the description reinforces with examples showing optional color usage. This adds meaning beyond the schema, particularly for the optional tag_fg and tag_bg parameters.

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

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

The description clearly states the tool's action: 'Add a new task Tag (with optional colors) to a Space's tag palette.' It uses specific verbs and resources, and distinguishes itself from sibling tools like clickup_add_tag_to_task and clickup_edit_space_tag.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear context. It advises using this tool before applying tags to tasks and directs the user to clickup_edit_space_tag for renaming or recoloring, offering clear differentiation.

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

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

Annotations indicate non-readOnly, non-destructive, and openWorldHint. The description adds return type (confirmation string or error) and error scenarios, but does not detail mutation behavior or side effects beyond creation. Adds value beyond annotations.

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

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

The description is well-organized into clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling) with no redundancy. Every section serves a purpose.

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

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

Given the tool has a single required parameter with nested fields, an output schema exists, and annotations are provided, the description fully covers usage context, return values, and error handling, making it 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 descriptions for each parameter are already detailed (e.g., 'Display name for the new view'). The description provides a brief example but does not add substantial meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states 'Create a task or page view scoped to a Space' which is a specific verb-resource combination. It also distinguishes from sibling tools like clickup_create_team_view, clickup_create_folder_view, and clickup_create_list_view by explicitly stating when not to use each.

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 clear 'When to Use' and 'When NOT to Use' sections with explicit alternatives for workspace-wide or folder/list-scoped views. Also includes error handling advice for 404 and 403 errors.

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

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

Annotations already indicate a write operation (readOnlyHint=false). The description adds detail about what is created (task or subtask), the return format (confirmation string), and error conditions. No contradictions.

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?

Well-structured with clear sections. Slightly verbose but every sentence adds value. Examples and error handling are helpful.

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?

Comprehensive: covers all major features (subtasks, custom fields, markdown, etc.), includes return format, examples, and error handling. Given the output schema exists, the description is 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?

Despite the schema having parameter descriptions, the context signals indicate 0% coverage. The description compensates with a summary of supported parameters (assignees, tags, custom fields etc.) and rich examples that demonstrate usage patterns.

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

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

Clearly states 'Create a task inside a List' with a specific verb and resource. Distinguishes from siblings like clickup_update_task and clickup_create_task_from_template in the 'When NOT to Use' section.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear guidance. Also includes error handling advice (400/404) which helps the agent diagnose failures.

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?

Describes behavior: reads local file, posts as multipart/form-data, file not echoed back. Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, consistent with mutation. No contradiction. Adds error handling details (ValidationError for path issues, 404 for wrong task ID).

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

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

Well-structured with sections (purpose, when to use, returns, examples, error handling). Front-loaded with core purpose. Slightly long but each section earns its place for a complex tool. Could be trimmed slightly but still effective.

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

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

Covers all necessary aspects: purpose, usage scope, alternatives, parameter behavior, return value, examples, error handling. No gaps given the tool's complexity and the presence of output schema (return values not needing further explanation).

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

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

Description adds meaning beyond schema descriptions: explains file_path must be local, filename defaults to basename, custom_task_ids usage with team_id. Examples demonstrate parameter combinations. Enhances understanding of how parameters interact.

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

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

Description clearly states 'Upload a local file to a task as an attachment (v2)'. It specifies the verb (upload), resource (local file to task), and version. Distinguishes from sibling tools like clickup_create_entity_attachment and clickup_get_entity_attachments.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections. Lists alternatives: use clickup_create_entity_attachment for v3 or file-type custom fields, use clickup_get_entity_attachments for reading. Clear guidance on prerequisites like custom_task_ids requiring team_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?

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: return format (confirmation string with id, hist_id, timestamp) and error handling for 404/403. No contradiction with annotations.

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

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

Well-structured with clear sections (purpose, endpoint, when to use, when not to use, returns, examples, error handling). Every sentence earns its place; 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?

Given the tool's complexity and the presence of annotations and schema, the description fully covers usage context, return values, error cases, and examples. It is complete for effective agent decision-making.

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

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

The input schema already provides descriptions for all parameters, so the tool description adds little beyond mentioning assignee/group_assignee for action items. With high schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states 'Add a comment to a task' and specifies the API endpoint. It distinguishes from sibling tools like clickup_create_threaded_comment and clickup_create_list_comment, making the purpose unambiguous.

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

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

Explicitly lists when to use (feedback, questions, handoffs, action items) and when not to use (threaded replies, list/chat view comments), naming alternative tools. Provides excellent decision guidance.

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

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

Annotations indicate non-read-only, non-destructive, non-idempotent. Description adds that it performs a POST request and returns a confirmation string with new task name and ID. Also mentions error handling (404). No contradictions. Small gap: no explicit mention of side effects beyond creation.

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

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

Description is well-organized with clear sections: overview, endpoint, usage guidelines, returns, example, error handling. No redundant sentences; every line serves a purpose.

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

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

Given the input schema describes parameters and an output schema likely returns the result, the description provides all necessary additional context: purpose, HTTP method, how to get template IDs, when to use, example, and error handling. Covers all key aspects for correct tool selection and invocation.

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

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

Input schema already describes each parameter (name, list_id, template_id). Description adds context by showing the endpoint pattern and explaining how to obtain template IDs via `clickup_get_task_templates`. Provides a concrete example. Schema coverage is 0% but parameters are described in the schema, so description adds complementary 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?

Clearly states 'Create a task in a List from a saved task template.' Specifies verb, resource, and distinguishes from sibling `clickup_create_task` (plain task). Mentions the HTTP POST endpoint for technical clarity.

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

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

Explicitly provides 'When to Use' and 'When NOT to Use' sections, with direct reference to alternative tool `clickup_create_task` for plain tasks. Offers actionable guidance on when this tool is appropriate.

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

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

Beyond annotations, the description discloses important behaviors: Custom Fields added at this level apply to every task and prevent moving the view, error handling for 404/403, and confirmation string return format.

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?

Well-structured with clear sections (purpose, when to use/not use, returns, examples, error handling), every sentence adds value without 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?

The description is comprehensive for the tool's complexity: it covers purpose, usage boundaries, parameter nuances, return type, and error scenarios, leaving no critical gaps for an AI agent.

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 adds meaningful context to parameters, especially the 'columns' field with its permanent effect, and provides an example usage. Schema descriptions are also present, but the description enhances understanding.

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 creates a view at the Everything Level of a Workspace, distinguishing it from other view creation tools by explaining the cross-Space scope and when to use alternatives.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections provide clear guidance, naming specific sibling tools (clickup_create_space_view, clickup_create_folder_view, clickup_create_list_view) for different contexts.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds that it posts to a specific endpoint, returns a confirmation string with ID/hist_id/timestamp, explains the nesting behavior, and notes error handling (404 for wrong comment_id). This fully discloses the operation's behavior.

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

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

The description is well-structured with clear sections (endpoint, when to use/not, returns, example, error handling). It is somewhat lengthy but every part adds value; could be slightly more concise.

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

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

Given the tool is a mutation with complex nesting semantics, the description covers endpoint, usage context, return format, error handling, and example—leaving no gaps. The presence of a rich output schema further supports 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?

The description does not describe parameters beyond an example. However, the input schema itself has thorough descriptions for all five properties, so the agent can rely on schema. Per guidelines, with schema coverage low (0% from description), baseline is 3; no additional value 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?

The description clearly states the tool's purpose as 'Reply inside an existing comment's thread.' It specifies the endpoint and distinguishes itself from top-level comment creation, which is directly relevant given sibling tools like clickup_create_task_comment.

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 explicit 'When to Use' and 'When NOT to Use' sections, naming specific alternative tools (clickup_create_task_comment, etc.), providing clear decision 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?

Goes beyond annotations by specifying the HTTP method (POST), endpoint, return value (confirmation string with key fields), and detailed error handling (400/404, specific error code TIMEENTRY_072 and workaround). Annotations already indicate non-readonly and open-world, but description adds rich behavioral context.

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?

Well-organized with sections (when to use, examples, error handling). Front-loaded with purpose. Slightly long but each sentence adds value; no fluff.

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

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

Given the complexity (multiple params, mutual exclusivity, default values, error codes) and the presence of an output schema, the description covers the key behavioral aspects, return format, and error scenarios comprehensively.

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% per context, but the description provides examples showing duration/stop mutual exclusivity and notes default team_id. However, many parameters (tags, assignee, custom_task_ids) are not individually described; the schema itself provides descriptions, so the description adds limited additional semantics.

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 starts with 'Log a completed (already-finished) time entry.' which is a specific verb and resource. It clearly distinguishes from sibling tool clickup_start_time_entry by stating when not to use (for running timers).

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 states when to use (backfilling time, logging completed blocks) and when NOT to use (starting a running timer, directing to alternative clickup_start_time_entry). Examples further clarify usage.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds value by explaining the API call details, return value, and warning about billing implications for adding view-only guests. No contradiction with annotations.

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

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

The description is well-structured with clear sections: API explanation, usage guidelines, return value, examples, error handling. It is detailed but not verbose, and front-loads essential 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?

Given the complexity of the tool (parameter naming confusion, billing implications) and the presence of siblings, the description covers all necessary aspects: purpose, usage, parameters, behavior, errors, and examples. Complete for effective tool selection and invocation.

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

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

Although schema description coverage is 0%, the description compensates by explaining the meaning of each parameter (team_id is workspace id, members are user ids, handle for @mentions, etc.) and provides an example. It adds clarity beyond the input schema.

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

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

The description clearly states it creates a User Group (called a Team in ClickUp's endpoint), specifies the HTTP method and path, and clarifies the confusing terminology (team_id vs group_id). It distinguishes from siblings like clickup_update_user_group and clickup_delete_user_group.

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 explicit 'When to Use' and 'When NOT to Use' sections, providing clear guidance on when to use this tool vs alternatives (e.g., use clickup_update_user_group for adding/removing members). It also mentions error handling and billing impact.

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

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

Annotations indicate this is not read-only and not destructive, but description adds specifics: it subscribes an endpoint, responds with webhook id and health object, and details error handling (400, 404). No contradictions.

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 well-structured with clear sections (purpose, when to use/not use, returns, examples, error handling). No redundant information, every sentence is useful.

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

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

Given the tool's complexity, annotations, and existence of an output schema, the description covers all necessary aspects: creation, filtering, wildcard events, return fields, and error codes. No gaps.

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

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

The input schema already describes each parameter, but the description adds value by showing usage examples and specifying error handling for invalid endpoint or unknown event names.

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

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

The description clearly states it registers a webhook to push events to an endpoint. It uses a specific verb ('Register a webhook') and resource ('ClickUp events'), and distinguishes from siblings like clickup_get_webhooks and clickup_update_webhook by indicating when not to use those.

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

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

The description explicitly states when to use (to wire into external systems, watch single list/task) and when not to use (to inspect/repair existing webhooks, for one-off reads). It also provides concrete examples of parameters.

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

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

Annotations already set destructiveHint=true. Description adds that deletion is permanent and irreversible, and explains error responses (404, Error string). Could mention cascading effects, but overall adds meaningful context beyond annotations.

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

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

Well-structured with clear sections: overview, when to use/not, returns, example, error handling. No redundant information; every sentence serves a purpose.

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

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

Covers core aspects: purpose, usage boundaries, example, errors. Missing potential details like permission requirements, but given annotations and output schema, it is sufficiently complete for deletion.

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

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

Schema coverage is 0% but schema itself has descriptions for both parameters. The description only provides an example for channel_id and omits explanation of workspace_id. Minimal added value; does not compensate for the lack of schema descriptions.

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

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

The description clearly states the tool permanently deletes a Chat channel (Channel, DM, or location-bound). It distinguishes from sibling tools like clickup_update_chat_channel by specifying that it is for deletion, not hiding/archiving.

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 provides 'When to Use' (remove an unneeded channel) and 'When NOT to Use' (hide/archive, recommending update instead). Includes an example and error handling, offering clear decision support.

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